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
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev