-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
False
-
None
-
False
-
Not Selected
Proposed title of this feature request
We should consider moving our configuration from a config map to a custom resource definition.
What is the nature and description of the request?
Operators should generally be configured by an accompanying CRD. Currently CMO uses a config map for that due to historical reasons. While developing and implementing a CRD is not complex, making the transition painless for users will be rather tricky.
Why does the customer need this? (List the business requirements)
A CRD has several advantages over a config map:
- The specification is well known and to a degree self-documenting
- We can specify validation and legal values right in the CRD.
- The APIServer will validate user resources based on our specifications, so users get immediate feedback on errors instead of having to check if their config was applied and check logs.
- Many users expect to interact with operators through a CRD
- Compatible with GitOps workflows.
- List any affected packages or components.
CMO
We should have a telemetry signal to track adoption.
- incorporates
-
RFE-3451 Replace the use of `user-workload-monitoring-config` ConfigMap with a custom resource
- Accepted
-
OCPSTRAT-1600 Declarative monitoring stack config
- New
- is cloned by
-
ACM-14052 Move CMO configuration to CRD(For ODF tracker)
- New
- is related to
-
OBSDA-451 Incorporate a clear monitoring story with self-managed Hosted Control Planes
- To Do
- is triggering
-
MON-1100 CRD based monitoring configuration feature gate
- In Progress
- relates to
-
OCPSTRAT-1782 OpenShift integration with external secret managers (Vault)
- New