[Pulp-dev] Pulp2 and directory permissions

Grant Gainey ggainey at redhat.com
Mon Sep 28 15:56:46 UTC 2020


Hello pulp-devs,

Recently an issue was opened due to some Pulp2-behavior causing problems
when one is migrating from Pulp2 to Pulp3. You can find the issue here:

  https://pulp.plan.io/issues/7445 <https://pulp.plan.io/issues/7445>

The crux is that python's os.makedirs(), its mode= parameter, and umask,
have results that aren't what the Pulp2 code actually expects. This
unexpected behavior then causes problems for pulp2-to-pulp3 migrations, if
the Pulp2 side of things is creating/syncing new things
post-pulp3-installation.

If you look at the writeup at https://pulp.plan.io/issues/7445#note-13 , I
am proposing a change to Pulp2 to standardize all the various makedirs() to
one existing utility-routine, and make sure the end result is what Pulp2
code expects. This will have the benefits of:

* making sure all Pulp2 code does the same thing,
* insures the results are what the Pulp2 code is actually expecting, and
* won't break the migration process

The downside is changes in a number of places in Pulp2, and in its plugins
(I know pulp_rpm is affected, I assume there will be other plugins)

The/another approach to this would be to extract the permission-cleanup
work that the pulp2topulp3migration installation does, into a script. The
admin would need to run the script prior to each migration-attempt. This
would address the immediate problem ("Migration fails if I sync new stuff
in Pulp2 post-migration-installation"), and be less intrusive. But it
requires more, manual, work from the migrating-user, increasing
migration-friction.

Can anyone see a better way to address this problem? I don't like making
changes to Pulp2 at this stage in its lifecycle, especially not general
ones like this; if anybody has a brilliant Better Way to approach this,
please chime in!

G
-- 
Grant Gainey
Principal Software Engineer, Red Hat System Management Engineering
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200928/ed1195b9/attachment.htm>


More information about the Pulp-dev mailing list