RPM packages for PULP

[praiskup]

We'd like to have RPM packages for PULP product(s). Starting with Fedora EPEL, or even Fedora would be nice.

Describe the solution you'd like
Since the software is shipped in PyPI already, we could start with pyp2spec <pypi_name> and increment.

Describe alternatives you've considered
We'll have to install it from PyPI, though RPMs are better for administrators running on RPM systems (metadata, security, dependency tracking, configuration, etc.)

Additional context
This is related to the Copr on Pulp initiative.

[praiskup]

I'm sure this wouldn't be very helpful, but I did a pulp-cli RPM experiment some time ago.

[ggainey]

TheForeman packages Pulp for EL8/9 already, so we have a good start :

http://yum.theforeman.org/pulpcore/

[mdellweg]

I'm sure this wouldn't be very helpful, but I did a pulp-cli RPM experiment some time ago.

Well, that would probably be helpful for sure, but for reasons orthogonal to this issue.

[dralley]

We discuss this today and came across a few major questions

1. Katello only builds/uses/supports certain versions long-term, what do you want your upgrade cadence to look like?
2. Are the current for-theforeman RPMs acceptable? Do they have to be published directly in Fedora?
   • The packages are currently built for enterprise linux, do we need a separate buildroot for Fedora?
3. How should migrations be handled?
   • Katello/Satellite/RHUI have external tools/scripts that manage upgrades, but standalone RPMs in a repo won't have this
   • Does it happen automatically? Does the user need to trigger it?

[praiskup]

Thank you for the update, and sorry for /me missing the meeting. If you ask me/us (the Copr team):

1. it is up to the upstream (you), I'd say .. the packages should be working, be "maintained", i.e. they should work and update reasonably, as long as everything works we don't care about versions
2. maybe yes? I'm not sure, have to take a look ... why isn't/wasn't the pulp_installer using those RPMs?
3. ideally, there would be some script in the RPM that we could run manually ... same as Katello/Satellite/others... does it have to be project-specific? In Copr we provide the script (actually alembic configuration) and deployments run the script when they upgrade, manually (resalloc applies DB migrations automatically, but that's a much easier model)

[dralley]

1. Good to know, sounds like from that perspective they would be fine

2. Well, we're not using pulp_installer anymore as an upstream solution, we mostly try to push container images. Katello/Satellite/RHUI/other products use the RPMs. The TL;DR is the RPMs are/were built by not-us, and don't really suit the upstream needs. For example we do want upstream users to pick up new versions and exercise new features faster than Katello and friends.

3. A script included with the package is the conclusion we also came to. That's basically what postgresql does. Doing it as part of an RPM postscript is needlessly magic and problematic (lots of questions about what happens if it fails, what happens if it takes too long and the computer gets shut down mid-transaction, etc.)