Pulp_installer 3.22 will be the last release for the installer

Announcements
#1

TL;DR:

Users of pulp_installer will be able to upgrade to pulpcore 3.22 (when it is available) using their existing Ansible Playbooks. However, no further releases of pulp_installer will be made.

Users wishing to upgrade to pulpcore 3.23+ will need to migrate their deployment to use containers. There are multiple options for running Pulp services as containers[0,1,2]. Upgrade instructions will be provided prior to the pulpcore 3.23 release.

Motivation:

Two main motivators: 1) User Feedback and 2) Too costly to maintain relative to a container based option.

User Feedback

  • If a user doesn’t already use Ansible, the installation of Pulp is seen as to large a barrier to entry.
  • When the intaller has any problem/error because it’s so complex, even long-time Ansible users aren’t in a position to figure it out.

Too costly to maintain relative to a container based option

  • The installer needs a lot of work for each OS version it supports. Containers need almost none.
  • The CI test matrix for supporting all of OS versions is huge and takes a lot of human time just to keep it going. It breaks very often.
  • Users need container based installs to run Pulp where they want, so having a container-based option is already a sunk cost
  • Having one installation asset, i.e. used by all users will give better results for everyone

[0] Multi-Process Images - Pulp OCI Images
[1] Single-Process Images - Pulp OCI Images
[2] Pulp Operator

3 Likes
What the current recommended way to run Pulp3 in production?
3.22 release
Domain get error during installation
To upgrade pulpcore and pulp_rpm with good compatibity
#2

I have questions: How are you building the containers (does that not rely on pulp_installer)? How will this affect pulplift dev boxes? Does this mean there won’t be any supported way to install Pulp outside of containers?

#3

So, from now on ( actually from pulpcore 3.23+ ) the only way to run pulp will be through containers. Right ?

Thank you very much for giving the reasons and benefits for this change.
I think everyone who has been involved with the use of pulp_installer has faced problems at some point.
On which operating systems will pulp be based from now on ?

If we want to check and test the new installer and how it works, can we do that ?
https://docs.pulpproject.org/pulpcore/installation/instructions.html
https://pulpproject.org/pulp-in-one-container/

#4

  1. We are building the container images without pulp_installer. They are built (and pushed to the 3 registries) by the CI on the pulp-oci-images repo. We are in the middle of writing complete manual build instructions for users that want them, this is what we have so far.

  2. You’ll need to replace your pulpleft dev box with an oci_env dev container.

  3. Outside of the 3 container solutions (multi-process container, the docker-compose, and pulp-operator), we will continue to maintain our manual install instructions. The RPMs will continue to be available, but they will still only be the equivalent of running “pip install”; the rest of the install steps will still be manual.

1 Like
#5

  1. You can still also do a manual install. See my previous reply for more info.

  2. Yeah, I totally empathize with users. I’ve been maintaining pulp_installer for 3.5 years and I hate to discontinue something I’ve worked so hard on.

  3. All the container images share a common base image that is based on CentOS Stream 8. We chose CentOS Stream 8 because we want to test pulp against the oldest version of python we support, Python 3.8. (EL9 only has Python 3.9). This will change to EL9 and Python 3.9 at some point in the future, but we have no plans currently. However, the manual install instructions will continue to support EL7, other variants of EL8, EL9, Fedora, Debian 11 and Ubuntu 22.04. We are open to adding steps for other distros as well. Our manual install instructions probably do need to be improved with OS-specific steps. (All those OS-specific steps were logic in pulp_installer)

  4. I mean, we do not have a new “installer” per se, we have the 3 container solutions + the manual install instructions. See the 3 links in the original post for the 3 container solutions docs. The manual install instructions are documented where you pointed to. The “pulp-in-one-container” page you linked to, now called the “multi-process container”, will be slimmed down to just a quick start guide, and will point to the new docs for full documentation.

1 Like
#6

The RPMs will continue to be available, but they will still only be the equivalent of running “pip install”; the rest of the install steps will still be manual

To release RPMs for Pulp we fully utilize the Ansible based installer, I’m looking to alternatives and I’ll probably change from calling the Ansible Installer, to something simillar to what Katello does in the installer, but only with Pulp, a standalone installation of Pulp. This I’ll take some time to be done, but it needs to be there to keep the same workflow that we have now, where each new RPM release performs a complete installation of Pulp.

@quba42

This will make us switch from Ansible to Puppet to at least have some sort of automation in the installation for pipelines and Dev Environments.

#7

Here are draft instructions.

They are technically correct, but I will try to make them clearer (in terms of when to run certain steps):

To render them rather than seeing the code, click “…” to the right of " docs/migration-pulp-installer-to-multi-process.md", then “View file”.

1 Like
#8

Could you provide an URL to point me at the code where you call the pulp_installer after RPM packaging? I am curious. I was considering to start using the puppet module from foreman-installer in order to receive a “Katello like” Pulp installation myself. My use case was to use this instance to pull the api.json for creating client gems.

Pulpcore 3.22.0 is GA!
#9

@mikedep333 @dkliban, before releasing a version of pulpcore, that no longer has a pulp_installer to go with it, the pulp-operator README, which is also used by the pulp-operator documentation could really use a rework/update!

I also have a suggestion for re-drafting the introductory paragraph in the pulp-oci-images README:

2 Likes
#10

Thanks @quba42! I merged these changes.