Currently, the monitoring stack is configured using a configmap. In OpenShift though the best practice is to configure operators using custom resources.

Why this matters

• We can add [cross]validation rules to CRD fields to avoid misconfigurations
• End users get a much faster feedback loop. No more applying the config and scanning logs if things don't look right. The API server will give immediate feedback
• Organizational users (such as ACM) can manage a single resource and observe its status

To start the effort we should create a feature gate behind which we can start implementing a CRD config approach. This allows us to iterate in smaller increments without having to support full feature parity with the config map from the start. We can start small and add features as they evolve.

One proposal for a minimal DoD was:

• We have a feature gate
• We have outlined our idea and approach in an enhancement proposal. This does not have to be complete, just outline how we intend to implement this. OpenShift members have reviewed this and given their general approval. The OEP does not need to be complete or merged,
• We have CRD scaffolding that CVO creates and CMO watches
• We have a clear idea for a migration path. Even with a feature gate in place we may not simply switch config mechanisms, i.e. we must have a mechanism to merge settings from the config maps and CR, with the CR taking precedence.
• We have at least one or more fields, CMO can act upon. For example
  • a bool field telling CMO to use the config map for configuration
  • ...

Feature parity should be planned in one or more separate epics.