search

pulp / pulpcore

Pulp 3 pulpcore package https://pypi.org/project/pulpcore/
GNU General Public License v2.0
310 stars 116 forks source link

RPM packages for PULP #5128

Open praiskup opened 8 months ago

praiskup commented 8 months ago

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 commented 8 months ago

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

ggainey commented 8 months ago

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

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

mdellweg commented 8 months ago

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 commented 8 months ago

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?

praiskup commented 8 months ago

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 commented 8 months ago

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.)

ipanova commented 2 months ago

@praiskup given current situation, I believe this is no longer needed? Can you confirm and close?