Use the same project for managing a k8s cluster and as a cluster management project
Problem to solve
The cluster management project workflow is confusing from a user perspective. If I create or add a cluster A to project A, and I select a project B as a cluster management project for cluster A, I will have two projects associated with the same cluster. That unchain significant complexity in the following way:
- It is difficult to understand which of the two projects is the actual owner of cluster A because both projects can perform similar operations on the cluster.
- The cluster management project does not indicate in any way that is associated with cluster A.
- Users can still create or add another cluster in the cluster management project. If the user decides to do that, they have to deal with the fact that the same project can act on a k8s cluster in two different ways.
Intended users
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
Proposal
Cluster management projects exist for the following reasons:
- GitLab Groups and instances do not have code repositories. That limits our capability of using CI to automate ops tasks for clusters created or added to any of them.
- We want to use different repositories for cluster management code and application code.
To address the first reason, I propose not to create or add k8s clusters in a GitLab group or instance directly. Instead, the user can specify which project, group, or instance can access the cluster resources. This is an example of how the user could specify this while creating or adding a cluster:
Alternatively, we could display a dropdown instead of an open text field to limit the sharing options to:
- The instance where the cluster lives.
- The group that contains the cluster management project.
- Any of the project’s siblings.
Cluster inheritance
To address the 2nd reason (separate application code from infrastructure code), cluster management projects won’t participate in the cluster inheritance tree. This helps us to set apart cluster management projects from projects that manage application code. The inheritance tree looks like this:
Advantages of this workflow
- Fewer artifacts to manage. All cluster management actions happen in a single project.
- The cluster has full control of what can access its resources.
- We don’t have to take measures to indicate that a project is managing a cluster. If a project owns a cluster, it is a cluster management project.