How can Lagoon support different operator/feature configurations per cluster.

[tobybellwood]

Given we now operate a DBaaS operator (amazeeio/dioscuri#7) in some clusters, and have custom configurations in others, we should develop an approach that would facilitate a Lagoon deployment to be customised per-cluster - allowing for the necessary combination of components, services and operators to be deployed.

This should help to reduce running non-utilised services, allow for better customisation and, if it was possible to specify each component for the Lagoon install in code, allow for repeatable, reusable Lagoon deployments.

Questions:

• What features are essential for a Lagoon (or Lagoon-remote) deployment?
• What features should be optional?
• Is there the ability to have pre-selected, community contributed (non-Lagoon) operators available - how would we vet this?
• What's the best mechanism for this - Does Lagoon become an operator itself, should each cluster effectively have a CRD?

[tobybellwood]

DBaaS operator (amazeeio/dioscuri#7)

Correction - dioscuri is the active/standby operator, in addition to the dbaas-operator...

[smlx]

I can imagine the easiest path for this would be helmfile as we do already for other k8s stuff.

Just need that Lagoon helm chart.. 😄

Operator would be great, but a lot more work.

[tobybellwood]

Now that we have https://github.com/uselagoon/lagoon-charts this is much easier!