Remote managed clusters inside the management cluster name folder

[alosadagrande]

Hi folks,

I have just the feeling that including the remote cluster configuration inside the management cluster folder is a clean way of know what clusters are being managed by the hub cluster. See here my folder structure. I personally find it easier to understand than create the clusters inside folder clusters/ the telco-gitops repository where you do not know what cluster is managed by which hub.

Inside the remote-clusters/ folder we have a base and config folder. The base must point to the telco-gitops operators' folder and/or a blueprint. I mean both ways can be ok, I can point to a blueprint, and if there is any operator that is not been included in that blueprint (e.g. ran-du-sno, where NMstate operator is not included) I can just add it in the customization base or create a new blueprint. Then, the config where the specific configuration of each managed cluster is applied.

Let me know your thoughts.

[williamcaban]

Our original structure with 4.6 was using a similar model and we found it didn't work well for organizations with multiple operations teams were each may have one or more clusters definitions they manage, maintain and have full control (e.g. think the situation where we have RAN team per zone, while Core teams cover larger areas, while MEC team go across). Now, this model works great for single-teams operations or flat organizations. It might be good to document the different patterns based on the type of operations team. If you like to document something for this model feel free to create a markdown entry in telco-gitops under /doc/user/operations-single-repo.md (the /doc path might not exist there yet but feel free to add it).

When thinking about the types of operations, these are some of the ones I keep in mind:

• Multi-tenancy Operations: this are Telcos that delegate the Operations of the platforms to different system integrations (SI's) or managed service providers. For these scenarios, the SI_1 manages a subset of clusters, while SI_2 manages a different subset. In this case, the independence of the cluster definitions and operations needs to be decoupled from the definition of the management cluster (which can be managed by another SI or the Telco)
• single-team operations or flat operations: these are small organizations with a single operations team (or single hierarchical group), or a single team for all the functions, for these teams it is usually easier to work out of a mono-repo configuration. The model you describe here will be perfect for them.
• multi-teams operations: these are large organizations that usually have different operations teams (e.g. one to cover east, other to cover west, or if big enough, another to cover north-east, etc). Some of these organization stretch political/country boundaries. In these cases, the required granularity control is far greater, and Muti-repo will be the common approach.

[williamcaban]

BTW, a pattern I like to explore is the use of the git file generators as a way to parametrized the definition of a cluster for an ApplicationSet without the need of a single approach. For example, be able to do multi-repo and local or mono-repo with the same approach. If you are for experimenting with options, that can be an interesting one to explore.