Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://issues.redhat.com/browse/AAH-2197
depends on ansible/galaxy#3248
What this is doing:
In the initial v1 implementation, legacy namespaces had an optional foreign key to a v3 namespace. Since many github logins don't conform to v3 namespace name requirements, those foreign keys weren't filled in.
Per AAH-2197 we are forcing all legacy namespaces to have a v3 namespace foreign key and to control access to the legacy namespace via rbac on the v3 namespace.
I've repurposed "provider" namespaces from the old v1 to expose the v3 namespace in the v1 viewsets. Now you can see what the actual v3 namespace for the legacy namespace is and how to get to it. When looking at the /owners endpoint, it will present the list of users that own the v3 namespace. Manipulating the v1 owners endpoint manipulates the v3 namespace's rbac.
How it works:
There's a bunch of helper utils written to build up an "algorithm" of sorts to consistently return some v3 suitable namespace name based on the github user's login and github id. The v3 namespace may match their login if valid or be a complete nonsensical name that they'd never use to push collections to, but that was the requirement given.
Along with making a bunch of v3 namespaces and linking them to the v1 namespaces, we have a github user validation scheme going on with trying to flip around email addresses on synced users to
<GITHUBID>@<SOMEPLACE>
until they actually login and have their true email set.All of this logic should be encapsulated and shared among the v1 sync code, the social auth code and the new django commands i've added.
Once the go-live date for beta galaaxy is hit, we need to remove all this v1 sync stuff and never do syncs again. If we eventually ship api/v1 downstream, then "sync" needs to be completely rethought. We shouldn't be second guessing our oauth provider and we shouldn't require a custom build of social-auth.
Testing
pulpcore-manager sync-galaxy-namespaces
encapsulates all of the magic in this PR. I decided not to implement it as a new REST endpoint for various reasons.architecture ...