[Pulp-dev] Pulp 3 Release Process Questions

[Robin Chan]

I'd like to summarize where we landed on this after several off-list
conversation.

Current understanding:
* All current stakeholders are good to consume the beta via PyPI
* The build team will create automation to create RPMs from packages
published on PyPI
* The publishing of RPMs will start at some point in the future after
Pulp developers and QE have put together a plan for where the RPMs
will be hosted, what infrastructure will be used to test them, and how
the packages will be signed.

We invite stakeholders to tell us when they need RPMs.

Robin

On Tue, Apr 24, 2018 at 9:41 AM, Patrick Creech <pcreech at redhat.com> wrote:
> On Mon, 2018-04-23 at 17:32 -0400, Brian Bouterse wrote:
>>
>>
>> Whoever does the packaging needs to determine how/where they want to run them.
>
> So, this is a sentiment I thought was addressed by Robin's e-mail, but I'll explicitly re-iterate here:
>
> The build teams role is not to be a black box that takes pulp's python packages and produces an rpm, no questions asked.  Our involvement in the upstream Pulp project is as a support role to help Pulp
> Engineering deliver on their desire to provide RPMs of pulp 3 to the upstream pulp community.  We are trying to work with Pulp Engineering to come up with a process suitable for you to deliver RPMs to
> your userbase.  This is why we started asking questions around what your teams expectations are with regards to rpm packages, where you want them delivered, etc...
>
> Our primary goal is to work with you and QE to help design and implement a process you can initiate at release time, and at the end have rpms, hopefully eliminating the need for constant involvement
> by a build team representative when it comes to release time.  Especially if it's pulps goal is to release more frequently.
>
>>
>> > Pulp 2's userbase primarily uses rpm based distributions.  If your support statement is 'It works on travis!' without ensuring pulp 3 works on your dominant userbase's machines, then I do not
>> > think
>> > that is a great attitude to have with regards to pulp's userbase.
>>
>>
>> I don't think our claim has to do with Travis. The quality claim for pypi is the same approach as with Pulp2: "we ran X unit tests and Y smash tests and there were 0 errors so we released". Users
>> can understand what our quality claim is by reading the functional tests. These quality checks will be run at pypi release time, and I think doing it at rpm release time would be consistent. Running
>> the unit and smash tests at packaging time on a given distro will provide that consistent quality claim in the packaged assets. Untested assets I think come with no guarantees to their users.
>
> So, I want to somewhat revise your statment on pulp 2 w/r to the quality statement: "we ran X unit tests and Y smash tests _on Z distributions_ and there were 0 errors so we released".  Each upstream
> supported distribution is a first class citizen of the entire testing stack to ensure proper functionality across the board.  This has helped identify problem areas across those distros that have
> helped lead to a more robust Pulp 2 experience.  I hope similar would be provided for pulp 3 as well, even for the 'install from pypi' experience.  This would help identify distribution specific
> issues, even in that use case.
>
>>
>> > And while build team is happy to provide automation, configuration, and setup to help package up pypi packages into rpms, I doubt we can commit to doing the legwork to ensure the code itself works
>> > specifically on said distributions. (i.e. selinux, systemd daemon scripts, etc...).
>>
>> I think we're on the same page here. The systemd scripts are provided in the docs by the devs. SElinux is it's own special thing, for now the plan is to ship pypi with selinux disabled so rpms could
>> do that too. I don't expect the build team to produce an SELinux policy.
>>
>
> I hope there is a long term item to develop an selinux policy.  I have a hard time imagining people are going to want to install production workloads on systems with selinux disabled....
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>