Bug 2062347
| Summary: | Missing ConfigMap oauth-serving-cert | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Kevin Cormier <kcormier> | ||||||||
| Component: | oauth-apiserver | Assignee: | Standa Laznicka <slaznick> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Xingxing Xia <xxia> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 4.8 | CC: | aos-bugs, eparis, kbempah, mfojtik, sberens, slaznick, surbania, tflower, wlewis | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | EmergencyConfirmed | ||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2022-03-24 10:36:25 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: |
|
||||||||||
Also seen with a 4.8.27 cluster on AWS. After consulting with @kbempah it appears we have not had a successful test run on OCP 4.8 during our current release cycle, so I am increasing the severity and confirming it is a blocker. We need confirmation first if these ConfigMaps should indeed exist in 4.8. They do in 4.9+. So console-operator is just syncing the `oauth-serving-cert` from the `openshift-config-managed` namespaces to the `openshift-console` namespace. Creating the CM in the `openshift-config-managed` namespaces is the responsibility of auth operator. Reassigning due to that fact. ** A NOTE ABOUT USING URGENT ** This BZ has been set to urgent severity and priority. When a BZ is marked urgent priority Engineers are asked to stop whatever they are doing, putting everything else on hold. Please be prepared to have reasonable justification ready to discuss, and ensure your own and engineering management are aware and agree this BZ is urgent. Keep in mind, urgent bugs are very expensive and have maximal management visibility. NOTE: This bug was automatically assigned to an engineering manager with the severity reset to *unspecified* until the emergency is vetted and confirmed. Please do not manually override the severity. ** INFORMATION REQUIRED ** Please answer these questions before escalation to engineering: 1. Has a link to must-gather output been provided in this BZ? We cannot work without. If must-gather fails to run, attach all relevant logs and provide the error message of must-gather. 2. Give the output of "oc get clusteroperators -o yaml". 3. In case of degraded/unavailable operators, have all their logs and the logs of the operands been analyzed [yes/no] 4. List the top 5 relevant errors from the logs of the operators and operands in (3). 5. Order the list of degraded/unavailable operators according to which is likely the cause of the failure of the other, root-cause at the top. 6. Explain why (5) is likely the right order and list the information used for that assessment. 7. Explain why Engineering is necessary to make progress. Created attachment 1865896 [details]
must gather logs
We've recreated on a 4.8.26 AWS cluster.
Attaching must gather logs (must-gather.local.5115599406220173222.tar.gz)
output from must gather shows:
ClusterID: 5b98a094-e6c8-4318-adae-5cf0503a5175
ClusterVersion: Stable at "4.8.26"
ClusterOperators:
All healthy and stable
Created attachment 1865897 [details]
output of oc get clusteroperators
Along with must gather, here's the output of
`oc get clusteroperators -o yaml` (clusteroperators.yaml)
Marked this as urgent as it is currently blocking our validation of RHACM 2.5 on OCP 4.8 deployments. Unless we get an actual description of the problem, I'm going to close this BZ as INSUFFICIENT_DATA. "ConfigMaps not being present leads to an authentication problem for RHACM." is most definitely not an adequate bug description. setting blocker- as this does not indicate a regression. Note this configmap was introduced in 4.9. I am unclear why there is the expectation this should be present in 4.8.
> This leads to an authentication problem for RHACM.
What is meant by this?
Thank you for letting us know that the `oauth-serving-cert` should not be present in OCP 4.8 This led us to some further investigation. We are using https://github.com/openshift/oauth-proxy as part of our management-ingress, and it seems that we recently updated the version of the image we pull in to be 4.9. So it makes sense that it is not compatible with OCP 4.8. Previously we have been using 4.5. Can you offer any guidance as to whether the version used needs to match exactly the OCP version? We currently support OCP 4.8, 4.9, and 4.10. A couple of comments for oauth-proxy. Generally oauth-proxy is bound to internal use inside OpenShift. We do not officially support usage outside of OpenShift core components. Fixes here are best efforts. Having said that for your concrete problem https://github.com/openshift/oauth-proxy/pull/238 should fix the problem. This fix is available starting from OpenShift 4.10. Closing this out as a duplicate of the actual BZ https://bugzilla.redhat.com/show_bug.cgi?id=2026860. *** This bug has been marked as a duplicate of bug 2026860 *** The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days |
Created attachment 1864937 [details] 500 error seen when trying to use OAuth for RHACM Description of problem: Installations of 4.8.12 and 4.8.13 are sometimes missing the `oauth-serving-cert` ConfigMap in the `openshift-console` and `openshift-config-managed` namespaces. This leads to an authentication problem for RHACM. Version-Release number of selected component (if applicable): How reproducible: Not sure. Steps to Reproduce: 1. Install 4.8.12 or 4.8.13. Actual results: Config maps are missing. Expected results: Config maps should be present. Additional info: