Kustomize - One Kustomization file to rule them all?

[tparikh]

Should we have one Kustomization file to deploy all of COSI or should each repo have Kustomization file it's component?

[NicolasT]

The way I'd lay things out:

• Have a base kustomization tree for the controller, as is in development: every cluster needs this to run
• Have some example kustomization tree for the example-provisioner, so this can be deployed (after deploying the controller, which is always a prerequisite) as a second step

Rationale for the base/controller one not to deploy the example-provisioner: there's no need to run the example in any cluster, e.g., when someone is working on another provisioner, and we want to reuse this base layer even when using other provisioners.

For the CSI plugin, it could theoretically be deployed by the controller manifests, but given it's developed in another repository (and hence likely has its own release cycle for now), I'd keep them separate, so have its own set of manifests.

For the CRDs: the controller and the sidecar depend on these to be installed. I believe in general the sidecar (which comes with a provisioner) has the controller as a prerequisite anyway. So I'd suggest the controller would deploy them.

The sidecar doesn't need to be deployed by itself so not applicable, should be part of whichever deployment mechanism is used for some provisioner to be installed, which we should leave up to the provisioner author.

[NicolasT]

In #26 I simplified the deploy/base layer to only deploy the controller (not hard-coding any namespace, cfr. #22), then add a deploy/fullstack overlay which deploys both the controller as well as the example provisioner.