Based on Architecture Blueprint: gitlab!54792. Having multiple containers (`Groups` and `Projects`) makes it harder to handle the growing demand for making features available on multiple levels. We can use our existing `Namespace` model as a container for features. This will also allow us to simplify our architecture. A core part of this epic is the introduction of `ProjectNamespace` which allows us to have a `Namespace` associated with every `Project` (which is different from the parent `Group` or personal namespace). We transition from ```mermaid graph TD; Group---Project; ``` to: ```mermaid graph TD; Group---ProjectNamespace; ProjectNamespace---Project; ``` As a result, essentially having: ```mermaid classDiagram Namespace <|-- UserNamespace Namespace <|-- Group Namespace <|-- ProjectNamespace ``` ## Iteration, Progress and Visibility For ease of iteration, visibility and progress reporting we can split the work on groups and projects consolidation into several phases. Note that these phases are not meant to be worked on sequentially or in water-fall manner and work on some parts may span over work covered in a different phases as well. This breakdown is rather an attempt to have a logical breakdown and grouping of the work in front of us. ### Phase I: [Define Namespace types and relationships](https://gitlab.com/groups/gitlab-org/-/epics/6697) - Defining ProjectNamespace, UserNamespace, and Group - Backfill ProjectNamespace for each Project in the DB - No real feature addition mostly structural preparations for tackling phase II work. - Records need to be preserved as a pair (so we need to handle project move, import, etc and also mirror with ProjectNamespace) ### Phase II: [Database updates to replace core usages of Project with ProjectNamespace](https://gitlab.com/groups/gitlab-org/-/epics/6768) - Keeping an eye on performance in general and query performance in particular needs to be a big part of the work done in phase II ### Phase III: [Migrate basic project functionality to Namespaces](https://gitlab.com/groups/gitlab-org/-/epics/6585) (:point_left: we are here) - Unify members/members actions - on UI and API level: https://gitlab.com/groups/gitlab-org/-/epics/8010+ - Starring - right now only projects are starrable - we can think if we want to bring it to the group level - Common actions: like destroying, transferring, restoring: this can be unified on the controller level and then propagated lower. Probably we have a lot of duplications there… - Archive: this works on project level. On group level we have yet similar mechanism for “pending deletion”. - Avatars serving and actions. ### Phase IV: [Migrate additional functionality from Project to ProjectNamespace/Namespace](https://gitlab.com/groups/gitlab-org/-/epics/8687) - Replace usages of Project with ProjectNamespace in the code - API changes to expose namespaces and namespace features. - Investigate if we extend API for `groups` or we introduce a `namespaces` endpoint and slowly deprecate `groups` and `projects` endpoints? - Break down each feature that needs to be migrated from Project to ProjectNamespace or Namespace. - Investigate if we can move a feature from `Project -> Namespace` directly vs `Project -> ProjectNamespace -> Namespace`. This can be decided on feature by feature case. - [Migrate Project#namespace to reference ProjectNamespace](https://gitlab.com/groups/gitlab-org/-/epics/6581) - [Routes consolidation between Project & ProjectNamespace](https://gitlab.com/gitlab-org/gitlab/-/issues/337103) - [Policies consolidation](https://gitlab.com/groups/gitlab-org/-/epics/6689) ### Phase V: [Cleanup](https://gitlab.com/groups/gitlab-org/-/epics/6944) - We should strive to do the code cleanup as we move through the phases, however not everything can be cleaned-up while something is still being developed, e.g. dropping DB columns can be done as last task, when we are sure everything is working, etc. Using this phase more as an overview. - Code cleanup - DB cleanup ### TBD - API adjustments to keep backwards compatibility ## Previous POCs ### Introducing project-level epics We explored the different approaches of introducing `ProjectNamespace`: - adding `Namespace#project` column: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66801 - adding `Namespace#project` but also removing `Project#namespace`: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65259 - adding `Project#project_namespace` column: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66800 ### Introducing group-level issues https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65715 ### Consolidating routing - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67664 - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69702