[Pulp-dev] pulp 2 to 3 upgrade experience concerns

[Brian Bouterse]

Thank you for raising this concern.

On Wed, Jul 31, 2019 at 10:06 AM Dennis Kliban <dkliban at redhat.com> wrote:

> Users of Pulp 2 that are upgrading to Pulp 3 need to make files stored in
> /var/lib/pulp/content readable by Pulp 3. There are two way to do that:
>
> 1. Install Pulp 3 with 'pulp_user' set to 'apache'. (Pulp will run as user
> 'apache')
>
> 2. Install Pulp 3 with any 'pulp_user' and any 'pulp_group'.
>     Recursively change group ownership of /var/lib/pulp/content/ to the
> value of 'pulp_group' and change the mode to 775 so that group can read the
> files.
>
> We have already started moving users toward the second approach by
> including the relabeling of /var/lib/pulp in the 2.20.0 release[0].
> However, I am concerned that this will lead to poor experiences for users
> that have a lot of content in their Pulp 2. Hours or days of upgrading
> their Pulp to 2.20.0+.
>
I hear this concern.


> I propose that we revert the change introduces in 2.20.0 and add an RPM
> scriptlet that changes everything back to 'apache:apache'. Then we can tell
> users that they have the two options from above when upgrading from Pulp 2.
>
The installer could be configured to work with these requirements It takes
those options currently AIUI. This proposal doesn't adjust the installer's
defaults does it?

>
> What are your thoughts?
>
I agree it takes time to perform that permission updating. The motivation
was that we didn't want Pulp as an application running as user apache,
especially with apache becoming a reverse proxy for Pulp3. We can rethink
that, but that is the current prevailing logic that I think of. I'm open to
other ideas here. If this is the case, and the filesystem is large, taking
time to fix these permissions is unavoidable (to me). The best thing we can
do is ensure it can be done online.

What if we had better alternatives to alleviate the long-running rpm
upgrade? We could make a script that adjusts the groups so that either pulp
or apache could be the owners, and the performs the relabeling while pulp2
2.19.z is online before the 2.20 upgrade. This would move the workload out
of upgrade time during downtime and to a pre-migration uptime. What about
ideas like that?

One more thought, this is specifically slow in NFS environments, we could
have users set the uid, gid on the NFS server itself.


>
>
> [0]  https://github.com/pulp/pulp-packaging/pull/98/files
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190731/342b1af5/attachment.htm>