Pulp

Ticket moved to GitHub: "pulp/pulpcore/1993":https://github.com/pulp/pulpcore/issues/1993

Problems¶

1. Currently, when auto-publish creates a publication, for distributions to go live with that the code needs to make a data change on the distribution. Here is an example in pulp_rpm. This requires the sync+publish code to lock on every distribution referencing the repository being sync'd. So instead of a lock like ["repository foo"] you get ["repository foo", "some distribution" "another distribution", "maybe a third distribution"].

2. Using both fields doesn't capture the user's intent. If a user wants to have a distribution always publish the latest publication setting the distribution.repository captures that nicely. If a user wants to have a distribution distribute a specific version of a publication (even if newer ones get created) setting distribution.publication captures that nicely. What we've got though is both fields being used together which captures conflicting requirements, they want the latest publication for a repository, but they also want this specific publication? If the distribution.publication is poiting to the latest publication then we're using two pieces of data when we only need one.

Why did we do it this way?¶

I suspect because it was convenient since the content app already knows how to serve distribution.publication so by setting that data the publication will serve correctly.

What to do instead?¶

1. For plugins that use publications, have their Distribution serializers validate to not allow both repository and publication at the same time.
2. Provide a migration to fix the data in cases where both are used.
3. Update the content app to find the latest publication when MyDistribution.repository is set and MyDistribution.publication is unset. This would happen here. This is roughly how the content app auto distributes non-publication plugins, see the implementation here.