Bug 1902320
Summary: | cluster-monitoring-operator fails on CreateContainerConfigError | ||||||
---|---|---|---|---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Martin Bukatovic <mbukatov> | ||||
Component: | Monitoring | Assignee: | Simon Pasquier <spasquie> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Junqi Zhao <juzhao> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 4.6 | CC: | alegrand, anpicker, erooth, frank.lamon, itbrown, jarrpa, kakkoyun, lcosic, mloibl, pkrupa, spasquie, surbania | ||||
Target Milestone: | --- | Keywords: | UpcomingSprint | ||||
Target Release: | 4.7.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-12-09 09:06:40 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: | |||||||
Attachments: |
|
Description
Martin Bukatovic
2020-11-27 18:07:24 UTC
Full list of related alerts: - Pod Namespace openshift-monitoring/Pod cluster-monitoring-operator-769d997849-xkrmg has been in a non-ready state for longer than 15 minutes. - Deployment Namespace openshift-monitoring/Deployment cluster-monitoring-operator has not matched the expected number of replicas for longer than 15 minutes. - Pod Namespace openshift-monitoring/Pod cluster-monitoring-operator-769d997849-xkrmg container Container kube-rbac-proxy has been in waiting state for longer than 1 hour. - 100% of the cluster-monitoring-operator/cluster-monitoring-operator targets in Namespace openshift-monitoring namespace are down. Created attachment 1734715 [details]
cluster-monitoring-operator pod file
For some reason, the cluster-monitoring-oeprator pod ended up with the "nonroot" SCC while it should normally be "restricted". Do OCS manipulate SCCs and related bindings by any chance? Jose, could you help us to direct the Simon's question to a proper subteam of OCS Dev group? At the same time, we also need to rule out an issue in ocs-ci. As noted in the bugreport, I already ruled out an effect of persistent storage configuration for OCP Monitoring. This also happens with OCP on Openstack OCP - 4.6.0-0.nightly-2020-12-04-165039 OSP - RHOS-16.1-RHEL-8-20201021.n.0 We are seeing this exact same issue upgrading from 4.5.23 to 4.6.8 And also a very similar issue (scc changing to nonroot on prometheus pods) doing an upgrade from 4.6.6 to 4.6.8 |