-
Epic
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
Deprecate Prometheus CR functionality in operator, without touching ServiceMonitor/PrometheusRule
-
S
-
False
-
-
False
-
To Do
-
0% To Do, 100% In Progress, 0% Done
-
-
Epic Goal
This epic/story is based on Slack thread:
https://redhat-internal.slack.com/archives/C01RQH8KQ87/p1768510672151089?thread_ts=1768421868.796559&cid=C01RQH8KQ87
At present `.spec.prometheus.enabled = true` will do several things:
- A) Create a Prometheus CR
- B) Create routes/ingress/service for Prometheus CR
- C) Create ServiceMonitors
- D) Create PrometheusRules
We want to get rid of behaviours A and B, but preserve behaviours C and D.
Thus, we are not getting rid of '.spec.prometheus.enabled' entirely, we are only removing the part of it that creates and manages a prometheus CR.
The reasoning for this can be found on the slack thread.
Acceptance Criteria
- From now on, when user has specified `.spec.prometheus.enabled`, we should NOT create the Prometheus CR.
- If the Prometheus CR exists (whether `.spec.prometheus.enabled` is true/false/undefined) we should delete it.
- If the Prometheus Service/Route/Ingress exists, we should delete them.
- E2E test in argocd-operator to verify deletion works as expected
- Add comments in `ArgoCDPrometheusSpec` to Host/Ingress/Route/Size fields indicating that the field is deprecated and no longer used.
- Remove documentation from docs/ in argocd-operator repo that refers to the A) and B) funtionality described above (for example, see insights.md)
- Note, as above, the following functionality should continue to work when .spec.prometheus.enabled is true:
- ServiceMonitors created by, for example, reconcileMetricsServiceMonitor/reconcileRepoServerServiceMonitor/reconcileServerMetricsServiceMonitor
- PrometheusRules created by, for example, reconcilePrometheusRule
SDLC Questionnaire
| S.No | Questions | Yes/No | Sample JIRA Epic |
|---|---|---|---|
| 1 | Does this Epic address a change in way the product is being used? (eg: Adding support for OpenShift GitOps to be used in ROSA cluster with HCP) | No | GITOPS-5223 |
| 2 | Does this Epic require a change in the application's runtime - Upgrade of operator-sdk, OLM, client-go, go-toolset ? | No | GITOPS-8104 |
| 3 | Does this Epic primarily dealing with introducing a new security related feature (eg: Introduce SSO support) | No | GITOPS-437, GITOPS-547 |
| 4 | Does this Epic primarily dealing with the modification of an existing security feature ? (Eg: Supporting of External Authentication for SSO) | No | GITOPS-8017 |
| 5 | Does this Epic require changes to any cryptographic library ( Eg: FIPS support for OpenShift GitOps) | No | |
| 6 | Does this Epic require any new or change in the existing cryptographic algorithms used in the product (Eg: Using GPG verification for manifests, Upgrading from SHA256 to SHA512) | No | |
| 7 | Does this Epic require any change in existing authentication mechanisms (eg: Argo CD Auth integration with OpenShift, Kerberos to OAuth) | No | GITOPS-437 GITOPS-547 |
| 8 | Does this Epic require any change in authorisation mechanism (Eg: Using RBAC and service accounts impersonation for App Sync) | /No | |
| 9 | Does this Epic require a change in the Communication protocol ( Eg: Using TLS to encrypt data traffic to/from Redis cache) | No | GITOPS-720 |
| 10 | Does this Epic require a change in how External Data is parsed and validated ? ( Eg: Change from JSON to Protobuf) | No | |
| 11 | Does this Epic require a change in core libraries or runtime (Eg: go compiler upgrade, Changing Operator SDK, controller-runtime, client-go versions) | No | |
| 12 | Does this Epic require exposing any internal service to internet (Eg: Allow exposing Argo CD Agent principal via Route, using ArgoCD CR) | No | |
| 13 | Does this Epic require a change in any existing gRPC service APIs | No | |
| 14 | Does this Epic require a change in any new external service (Eg: Support for OCI container registry for storing manifests) | No | |
| 15 | Does this Epic require a change in the tenancy model ? (Eg: Supporting Apps/Appsets in Any namespace, cluster and repo credentials in any namespace) | No | |
| 16 | Does this Epic require any addition/modification of RBAC resources (Service Account, Role, RoleBinding, ClusterRole, ClusterRoleBinding) ? | Yes | |
| 17 | Does this Epic require a feature that needs to be enabled only for cluster scoped Argo CD instances ? | No |
Definition of Done
- Code Complete:
- All code has been written, reviewed, and approved.
- Tested:
- Unit tests have been written and passed.
- Integration tests have been completed.
- System tests have been conducted, and all critical bugs have been fixed.
- Tested on OpenShift either upstream or downstream on a local build.
- Documentation:
- User documentation or release notes have been written.
- Build:
- Code has been successfully built and integrated into the main repository / project.
- Review:
- Code has been peer-reviewed and meets coding standards.
- All acceptance criteria defined in the user story have been met.
- Tested by reviewer on OpenShift.
- Deployment:
- The feature has been deployed on OpenShift cluster for testing.
- Acceptance:
- Product Manager or stakeholder has reviewed and accepted the work.
