Create issue template(s) for transitioning features to different namespaces

Problem to solve

As teams evaluate and move features from one namespace to another (project, group, instance) they are likely to go through a similar process, evaluation, and problem to solve. This issue is to develop a template to aid teams through this process.

Proposal

Develop an issue template to be used when evaluating and/or moving features from one namespace to another.

Generally, there are a few 'types' of features that can live at both project and group levels:

• Resource based features
  • E.g. issues, epics, members, routes where we would want these resources to be created both at group and project level. This is where the current groups and projects consolidation can already help.
• Settings related features
  • E.g. some settings need to cascade down the hierarchy. Some work on that has been done, more thorough investigation might be needed for each case.
• Aggregations
  • E.g. some computation for a set of resources is needed at project level as well as group level. This has yet to be tacked, but the groups and projects consolidation could help make it scale better if resources are linked to ProjectNamespace.

Guidelines

Resource based features

To migrate resource based features, existing functionality will need to be supported. This can be achieved in two Phases.

Phase 1 - Setup

• Link into the namespaces table
  • Add a column to the table
  • E.g. in the issues, a project id currently points to the projects table. A link to the namespace table needs to be established.
  • Modify code so that any new record already has the correct data in it
  • Backfill

Phase 2 - Prerequisite Work

• Investigate permission model as well as any performance concerns related to that
  • Permissions need to be checked and kept in place
• Investigate what other models need to support namespaces for functionality dependent on features you migrate in Phase 1
• Adjust CRUD services to point to the new column you added in Phase 1
• Adjust APIs(REST and GraphQL) to point to the new column you added in Phase 1
• Consider performance when fetching resources

Introducing new functionality is very much dependent on every single team and feature. Some inspiration of what needs to be considered is captured here (see Phase 3 and Phase 4).

Settings related features

Right now, cascading settings are available for NamespaceSettings. By creating ProjectNamespace, we can easily use this framework to make sure that some settings are applicable on the project level as well.

When working on settings, we need to make sure that:

• they are not used in join queries or modify those queries
• that updating settings is taken into consideration
• if we want to move from project to project namespace, we need to follow similar database process as described above.

Aggregations

TBD

General considerations

• When moving features from admin to group, do users understand the reach of the change now that the change is within a specific scope? Does the UI need to be adjusted to inform users of the reach?

Issues/Epics that tackle migration

Feature	Link	Status
Workspace Level Policy Management	&6881 (closed)
Consolidate VSA Group & Project into a single object	#367532 (closed)	Research
Support for Kubernetes agents at Workspace level	#357516 (closed)