search

operate-first / support

This repo should serve as a central source for users to raise issues/questions/requests for Operate First.
GNU General Public License v3.0
15 stars 25 forks source link

Introduce resource bundling to apps repository #684

Closed larsks closed 2 years ago

larsks commented 2 years ago

[This is a rewrite of operate-first/support#735 intended to make it a better issue for our new interns.]

Background context

We manage our OpenShift clusters through the apps repository, a collections of Kubernetes YAML manifests that are processed with Kustomize to realize resources in our clusters.

The Kustomize overlays that reflect each managed cluster currently include only individual resources. In other words, if we are adding a component to OpenShift such as the acme operator, we need to install a namespace, a clusterrole, and a clusterrolebinding. That means the relevant kustomization.yaml file includes in the resources section:

- ../../../../base/core/namespaces/acme-operator
- ../../../../base/rbac.authorization.k8s.io/clusterrolebindings/acme-operator
- ../../../../base/rbac.authorization.k8s.io/clusterroles/acme-operator

Any cluster on which we want to use the same operator needs to include the same three lines, and if we want to remove the operator from a cluster we need to remove these lines.

The problem with this arrangement, especially as the list of resources grows larger, is that it is possible to inadvertently neglect to add one of the necessary lines when adding the feature, or one might accidentally leave one or more of the lines in the file when removing the feature. These sort of bugs could in theory impact the operation or the security of the cluster.

In operate-first/support#735, we discussed an alternative repository layout that would make these sorts of problems less likely. We can bundle related resources so that they can be included (or removed) with a single line in the relevant overlay. If we continue the example using the resources necessary for the acme operator, the overlay would contain only:

- ../../../../bundles/acme-operator

And in cluster-scope/bundles/acme-operator, we would find a kustomization.yaml file with:

- ../../../../base/core/namespaces/acme-operator
- ../../../../base/rbac.authorization.k8s.io/clusterrolebindings/acme-operator
- ../../../../base/rbac.authorization.k8s.io/clusterroles/acme-operator

Prerequisite knowledge

Suggestions on how to proceed with this issue

mubariskhan96 commented 2 years ago

/assign @mubariskhan96

mubariskhan96 commented 2 years ago

I was trying to figure out if there's a way to figure out what resources are associated with a given operator. For example, for two operators with similar sounding name, its hard to tell which resource is for which operator. Like, in this file https://github.com/operate-first/apps/blob/master/cluster-scope/overlays/prod/moc/smaug/kustomization.yaml: for the fybrik operator, there are 3 namespaces:

And firstly, I want to confirm my understanding that there are three operators declared in these 3 lines above- fybrik-applications, fybrik-blueprints and fybrik-system.

and there are many resources:

I'm trying to understand, which resource corresponds to which of the 3 fyrbrik operators. Is there a way to tell that? Thanks!

edit: or is it the case that, there's one operator fybrik, and all these resources are associated to it.

HumairAK commented 2 years ago

I believe this is done, and we're now using bundles, closing -- reopen of there's more.