Bug 1869732
| Summary: | Fail to deploy a service monitor for user workload monitoring that references a secret for TLS configuration | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Simon Pasquier <spasquie> |
| Component: | Monitoring | Assignee: | Simon Pasquier <spasquie> |
| Status: | CLOSED ERRATA | QA Contact: | Junqi Zhao <juzhao> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.6 | CC: | alegrand, anpicker, erooth, kakkoyun, lcosic, mloibl, pkrupa, surbania |
| Target Milestone: | --- | Keywords: | UpcomingSprint |
| Target Release: | 4.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-27 16:29:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
It has been fixed upstream in https://github.com/prometheus-operator/prometheus-operator/pull/3413 tested with 4.6.0-0.nightly-2020-08-23-185640, and followed the steps in Comment 0, issue is fixed # oc -n openshift-user-workload-monitoring logs $(oc -n openshift-user-workload-monitoring get po | grep prometheus-operator | awk '{print $1}') -c prometheus-operator | grep "level=warn" no result Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4196 |
Description of problem: The prometheus operator running in the openshift-user-workload-monitoring namespace will fail to reconcile when a user submits a service monitor that references a secret (or configmap) for the TLS configuration. Version-Release number of selected component (if applicable): 4.6 How reproducible: Always Steps to Reproduce: 1. Enable user workload monitoring 2. Create a configmap for future reference apiVersion: v1 data: ca.crt: test kind: ConfigMap metadata: name: ca-cert-demo namespace: default 3. Create a service monitor referencing the configmap above apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: app: demo name: demo namespace: default spec: endpoints: - port: web tlsConfig: ca: configMap: key: ca.crt name: ca-cert-demo selector: matchLabels: app: demo Actual results: The prometheus operator's logs show warnings: level=warn ts=2020-08-18T14:06:02.864503096Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="SecretOrConfigMap can not specify both Secret and ConfigMap" servicemonitor=default/demo namespace=openshift-user-workload-monitoring prometheus=user-workload Expected results: No warbubg in the logs. The prometheus operator processes the service monitor successfully. Additional info: