[Pulp-dev] Pulp 3 Release Process Questions

[Patrick Creech]

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....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180424/971ae3a2/attachment.sig>