Namespace refactor

Summary

The overall point of the task is to future-proof the data model to accommodate the following things we know we will be implementing in the future:

• A ‘partner’ designation
• Other designations besides ‘partner’, or perhaps even levels of ‘partners’
• Consuming content from multiple SCMs, not just GitHub

Key concepts

• Namespace will be unique to Galaxy. Every user will map to at least 1 namespace.
• Many Provider (i.e., GitHub, GitLab, Atlassian, etc.) Namespaces will map to a Namespace.
• A given Provider Namespace can only map to one Namespace.
• A Namespace is not a ‘partner’. ‘Namespace’ and ‘partner’ are two separate concepts.
• In the future, a Namespace may be designated as a ‘partner’ by simply turning a Namespace attribute on or off.
• We don’t know today who or what a ‘partner’ is.
• We do know we need to deliver content by Namespace.Repository_Name.Content_Name.
• Because of wanting to deliver content based on Namespace, and not Provider_Namespace, every Provider_Namespace needs to map to Namespace, as stated above…

We’re allowing users to create a Namespace for the following reasons:

• Namespace does not hold any special meaning. As mentioned above, a Namespace is not automatically a ‘partner’.
• A Namespace creates a nice mechanism for anyone to have a public Profile within Galaxy that is completely separate from their Provider Profile(s)
• A Namespace allows everyone the ability to aggregate their content repositories from multiple Providers and Provider Namespaces under a single Galaxy Namespace.

Task Work

We’ll know this task is complete when the following items are complete:

• Create new models: Namespace, Provider
• Change the existing Namespace model to Provider_Namespace. Provider_Namespace is simply a one-to-one with a GitHub (or any future SCM) namespace. In GitHub, a namespace can be a username (e.g., geerlingguy), or an Organization (e.g., Ansible).
• The combination of Provider and Name is unique within the Provider_Namespace model.
• There is a one-to-many relationship from Provider to Provider_Namespace. A Namespace can have many Provider_Namespaces, but a given Provider_Namespace can only belong to a single Namespace.
• There is a many-to-many relationship between User and Namespace. A user can own many Namespaces, and a Namespace can belong to many users.
• A namespace matching the user’s username will automatically be created for a user the first time they login.
• A user can create a Namespace. (This means that Namespaces are created on a first-come-first-serve basis).
• A user can add other users as owners (i.e., admins) of a given Namespace.
• Users can associate any of their Provider_Namespaces to their Namespaces. As stated above, the API and UI must enforce the notion that a Provider_Namespace can only belong to a single Namespace.
• Users can update the profile information for a Namespace
• Populate the Namespace table with the existing Provider_Namespace values, such that there will initially be in the data a one-to-one mapping from Namespace to Provider_Namespace, and make the correct user association to Namespace. For example, today, we have a Namespace row for ‘geerlingguy’. After the data migration, there will be a row in Namespace for ‘geerlingguy’, and it will be associated with the ‘geerlingguy’ row in the Provider_Namespace table. The Namespace row for ‘geerlingguy’ will be associated with the ‘geerlingguy’ user account.

[cutwater]

During creation of a new top-level Galaxy namespace, the process will make an API call to GitHub and check to see if the new name matches an existing GitHub organization name. If it does, the user must already be part of the GitHub organization. For example, if attempting to create an ‘ansible’ top-level namespace, the user must be part of the GitHub ‘ansible’ organization within GitHub.

This change makes our ACL model bound to GitHub, doesn’t it? How does it correspond with our plans of adding GitLab support in a future and being hosting-agnostic?

[chouseknecht]

Namespace refactor