discussion: operators and operational ownership of created cloud components

Hi,

I do like the concept of abstracting operational complexity with operators and offering the Kubernetes API to provision and maintain cloud resources. Especially on databases though there might still be an operational component left.

For this I would like to start a bit of a discussion and start by bringing in a suggestion:

Usually there are DBA's taking care of operational aspects of Databases (also in the cloud), making sure they are monitoring and action is taken when they are faulty.

This operational ownership shifts a bit with using an operator - technical a developer can deploy a database by defining the CR and applying it. The question is: should this person then also be responsible for operating the DB?

An potential concept could be that DBA's are the ones maintaining the operator and encoding (config) compliance and operational requirements into the operator. Thus every DB created this way will adhere to the policies set by the DBA.

DBA's could maintain general operational ownership and have generic monitoring created via the operator as well.

What we would need for that:

• the operator would need to support setting those requirements via config
• the operator would need to bridge metrics/telemetry from the cloud resources into a common monitoring channel (like making it available via a metrics endpoint that then can be scraped via PodMonitor/ServiceMonitor)

This is not fully thought through yet and is just meant as a basis for discussion.

This issue names no files, tests, or entry points. Start by reviewing the proposed operator configuration requirements and metrics or telemetry integration, then clarify the ownership model and concrete acceptance criteria before implementation.