- This enables us to use a scope to query all clusters in group
hierarchy order in one query, and also enables us to union to instance
clusters later.
- Handle case where clusters not present at level. In which case the
query should go ahead and return the next level's clusters.
- Swap with new CTE query behind Feature flag. This FF is default
disabled.
Now we have terminals for instance and group clusters we can remove the
FF now. Deploying to instance clusters has been working without
complaints too.
There are two cluster hierarchies one for the deployment platform and
one for controllers. The main difference is that deployment platforms do
not check user permissions and only return the first match.
With this MR, group clusters is now functional, so default to enabled.
Have a single setting on the root ancestor group to enabled or disable
group clusters feature as a whole
- Rename ordered_group_clusters_for_project ->
ancestor_clusters_for_clusterable
- Improve name of order option. It makes much more sense to have `hierarchy_order: :asc`
and `hierarchy_order: :desc`
- Allow ancestor_clusters_for_clusterable for group
- Re-use code already present in Project
Look for matching clusters starting from the closest ancestor, then go
up the ancestor tree.
Then use Ruby to get clusters for each group in order. Not that
efficient, considering we will doing up to `NUMBER_OF_ANCESTORS_ALLOWED`
number of queries, but it's a finite number
Explicitly order query by depth
This allows us to control ordering explicitly and also to reverse the
order which is useful to allow us to be consistent with
Clusters::Cluster.on_environment (EE) which does reverse ordering.
Puts querying group clusters behind Feature Flag. Just in case we have
issues with performance, we can easily disable this
Even though we currently only should have one group for a cluster, we
allow the flexibility to associate to other groups in the future.
This also matches the runner <=> groups association.
- Adds Cluster#first_group, aliased to Cluster#group. For the
conceivable future, a cluster will have at most one group.
- Prevent mixing of group and project clusters. If project type
clusters, it should only have projects assigned. Similarly with groups.
- Default cluster_type to :project_type. As it's very small table we can
set default and null: false in one release.
GitLab Bot