Conversation
100c884 to
055cb76
Compare
mdellweg
left a comment
There was a problem hiding this comment.
Thank you for looking into this!
| @@ -0,0 +1 @@ | |||
| Prevent container distributions from overlapping other distribution base paths. Pull-through distributions **NEED** to be fixed before upgrading pulpcore; run `pulpcore-manager container-repair-pull-through-distributions` to repair existing distributions. | |||
There was a problem hiding this comment.
Given that the constraint is a trigger only looking for new base_paths being inserted, you might get away with a few 500 if you run the command after updating...
There was a problem hiding this comment.
Yeah, but this is meant to also be backported to older versions so I didn't want to include a forced migration.
There was a problem hiding this comment.
I was trying to say the actual situation is even better than the changelog states (and that is OK, so this is not a request to change.).
Even after upgrading, it's still better late than never to run the repair.
|
|
||
| return value | ||
| validate_registry_path(value) | ||
| # Ensure we follow pulpcore's cross-distribution overlap validation in addition to the OCI rules. |
| # This is the temporary fix for pull-through distros violating core's overlapping base-path rule | ||
| # The user must supply base-path and name as the same value, then after we validate they are good | ||
| # we set base-path to an UUID and use the name to construct the prefix of new distros' base-paths | ||
| # avoiding the overlapping problem; base-paths can share prefixes, but one must not be a subset of | ||
| # another. A proper fix should have us move off of core Distributions all together. |
There was a problem hiding this comment.
This get's me thinking:
Would it help to allow the core.base_path to be Null?
Or should we add a (hidden to the user) name_scope field so container appearing on "v2" could enforce the overlap rules completely independent of all the plugins appearing on "pulp/content"?
But then you said in the oci-registry there is no such restriction at all, right? We just need to make sure container keeps clear of the "pulp/content" paths. (That could be name_scope=null.)
How does pulp_container scope by Domains again?
There was a problem hiding this comment.
As it is currently, domains become the first part of the name when enabled. Normal upload/sync of nginx becomes /v2/nginx, with domains on it becomes /v2/{domain_name}/nginx, even within the default domain.
Right now we use the content app solely for the final redirect to download the blob artifacts. We use the base-path uniqueness rules to enforce each repository/image has a unique name, but other than that we don't care about base-path. In fact using pulp-container with other plugins means we have fewer available names we can use for a image which is probably not what we want. Allowing base-path to be nullable could help, but I think we should just add a new field like name_scope that is required, and then derequire base-path and set it to a UUID, if we want to stick to using Distributions. If users see base-path can be null they will want to try to use it for other plugins and probably break those plugins.
055cb76 to
6199d76
Compare
fixes: pulp#2494 Generated-by: gpt-5.6-sol
6199d76 to
78258bb
Compare
What this does
Repair command
The command repairs distributions where name matches base_path. It leaves mismatched distributions untouched and reports them for manual handling.
Tests
Closes #2494