Drop Passenger support

tl;dr: I’m proposing to drop Passenger support for Foreman 2.5 and always use Puma.

Context

Since Foreman 2.1 we have defaulted to using Puma instead of Passenger. Originally this was discussed in this RFC:

Back then we said that we want to keep Passenger supported so we can switch back if there are problems. We have happily used that while fixing some gaps in functionality and I’m glad we did, but I believe we have full feature parity now.

That makes me think it’s time to drop Passenger support. This will allow developers to use techniques like websockets (likely via ActionCable) which we weren’t able to support with Passenger but does work with Puma.

Affected projects

There are 3 areas I can think of that are affected:

Packaging

In packaging it means dropping packages. That is easy. In fact, it makes the Ruby 2.7 migration easier if we first drop Passenger because it means we don’t have to rebuild them (and they’re painful to build)

Installer

In the installer we have a --foreman-passenger boolean flag. It would mean dropping that flag and all code to support it. Given that we already have a boolean to switch back and forth, it can already migrate to Puma if any user hasn’t switched.

SELinux

Our SELinux policy has code to support Passenger that can be dropped.

Foreman

In Foreman itself there are some code paths (in particular during initialization) to support Passenger.

Suggested plan & timeline

Completing the removal before Ruby 2.7 makes that migration easier. Since that’s actively worked on, it would make sense to complete this work in the 2.5 timeframe.

A compromise could be to remove it from packaging and the installer but leave the code in core until Foreman 3.0 (planned after Foreman 2.5).

It also means we should add a note to Foreman 2.4 announcing the deprecation.

Unless there are objections, I’d like to proceed with this soon so we are ready well before stablization week is here.

6 Likes

Sounds as a good plan. I think Foreman 2.6 is supposed become 3.0, so the compromise would be there for one release. But I’d be happy to drop the code in 2.5 already if time allows.

Thanks for the addition @Marek_Hulan. I knew this but will add it to the RFC so it’s easier to read.

Thanks for working on this, definitely a challenging task with a lots of hidden dragons.

I remember there is passenger recycler helper in foreman-maintain that can be removed too. It was used by customers stuggling with memory problems until we figured out the problem. Just out of curiosity, do we plan to have similar tool for Puma? For example GitHub - schneems/puma_worker_killer: Automatically restart Puma cluster workers based on max RAM available

I do not propose to use this for default configuration, but having ability to easily turn it on can be very convenient in case customers suffer from memory problems after an upgrade. This can give us time to investigate the issue.

I haven’t looked into that and haven’t seen posts in the community that indicated a need for it.

On a related note: foreman-selinux can also be cleaned up when Passenger support is dropped.

Yesterday we merged the packaging and installer PRs. There’s also a documentation PR:

@lzap would you mind taking a look at SELinux?

On that.

It was a pleasure:

This probably deserves a headline feature and upgrade warning in