Pulp

This issue is in assigned...will update as soon as new account created/updated.

Notes from the Pulp team meeting on this:

Background info

Agreed at PulpCon not to build RPMs and have QE test them as officially supported method of Pulp 3 delivery. Did not have urgent internal driver & didn't want to spend time testing what we thought would be required ahead of knowing what katello or Ansible Galaxy stakeholders required just due to past requirements.

RPMs
- Pulp 2 dropped in fedora dropped (QE & dev more time to focus on current priorities)
- f30 dropped mongo dependency, Pulp 2 dropped ahead of this
- Pulp 3 internal ci running on f29 now
- QE main goal - testing for stakeholders with urgent/near term needs
- source install is what is currently tested
- PyPI - main focus for now - it can be added to our CI - easily out of sync
- pulp smash functional & unit tests run during publish process before pushing new asset to PyPI
- Galaxy - reuse PyPI and repackage into containers
- Katello want containers
- Install from source is current QE testing
- dev goal - CI
- stay platform agnostic

Fedora
Has it's own build process
- Can lag behind
Auto rebuild

This is unofficial upstream Pulp/downstream Fedora
- how do we communicate availability
- db migrations
- Does ansible scripts handle upgrade?

Work involved:
- Packaging the several dependencies of Pulp3 in Fedora before packaging Pulp & the specified plugins
- Figuring out any scriptlets for upgrades, including Ansible
- Trying to get it done in time for the Fedora 30 release schedule

Conclusion
RPMs are still not an officially supported upstream deliverable. No ask of upstream Pulp to officially support or test them.
RPM specific issues will be likewise not be prioritized. Pulp Developers (Mike) will spend time on this because it does drive engaged user uptake which will provide more feedback to improve quality.

We just held another meeting (myself, bmbouter, asmacdo, pcreech & kersom).

We agreed that:
1. My work on the Summit prep will continue to be higher priority than this.
2. I will reach out to Neal Gompa soon to see if the RPM packaging is what he wants; particularly with respect to #3.
3. I will continue to adapt ansible-pulp for the RPM scenario (currently it has the PyPI & source install scenarios.)
4. It will not be that much work to do #3.
5. Creating an RPM like "pulp" with fixed RPM scriptlet logic is not a huge amount of work, but undesirable because of duplicate effort and the fact that it is non-configurable, where as ansible-pulp is configurable. (Although Debian packages with debconf could be configurable.)

Not addressed in the meeting due to lack of time is the upgrade scenario. That is not addressed yet with ansible-pulp & PyPI / source installs yet either.

Should we close this epic? Keep it open? Close most of the tasks since most of the the packaging work has already been done by Katello?

I am in favor of closing this. We do not have the capacity to follow through with this contribution. Given our limited capacity, I believe we need to focus on making Pulp's upstream the most usable and leave the OS packaging to others.