-
Bug
-
Resolution: Won't Do
-
Major
-
None
-
4.15.z, 4.16
-
Moderate
-
No
-
Rejected
-
False
-
-
Release Note Not Required
-
In Progress
Description of problem:
After configuring external OIDC, cluster displays "v1.oauth.openshift.io" and "v1.user.openshift.io" apiservices "False (FailedDiscoveryCheck)" which can lead to user confusion.
Version-Release number of selected component (if applicable):
4.16.0-0.nightly-2024-02-26-155043
How reproducible:
Always
Steps to Reproduce:
1. Install fresh HCP env and configure external OIDC as steps 1 ~ 4 of https://issues.redhat.com/browse/OCPBUGS-29154 (to avoid repeated typing those steps, only referencing as is here). 2. Verified the described "two issues" in https://issues.redhat.com/browse/OCPBUGS-29154 indeed are gone now. 3. Check `oc get apiservices`, they becomes False as below: $ oc get apiservices | grep False v1.oauth.openshift.io default/openshift-oauth-apiserver False (FailedDiscoveryCheck) 171m v1.user.openshift.io default/openshift-oauth-apiserver False (FailedDiscoveryCheck) 171m $ oc get apiservices v1.oauth.openshift.io -o yaml apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: creationTimestamp: "2024-02-28T06:50:12Z" ... status: conditions: - lastTransitionTime: "2024-02-28T09:20:52Z" message: 'failing or missing response from https://172.30.18.228:443/apis/oauth.openshift.io/v1: Get "https://172.30.18.228:443/apis/oauth.openshift.io/v1": context deadline exceeded (Client.Timeout exceeded while awaiting headers)' reason: FailedDiscoveryCheck status: "False" type: Available $ oc get apiservices v1.user.openshift.io -o yaml apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: creationTimestamp: "2024-02-28T06:50:12Z" ... status: conditions: - lastTransitionTime: "2024-02-28T09:20:52Z" message: 'failing or missing response from https://172.30.18.228:443/apis/user.openshift.io/v1: Get "https://172.30.18.228:443/apis/user.openshift.io/v1": context deadline exceeded (Client.Timeout exceeded while awaiting headers)' reason: FailedDiscoveryCheck status: "False" type: Available 4. The backend service and pods are reachable from kube-apiserver, though: $ oc get po -n clusters-$HC_NAME --kubeconfig $MGMT_KUBECONFIG -o wide | grep oauth-apiserver openshift-oauth-apiserver-654477d69c-22q88 2/2 Running 0 4h36m 10.129.2.20 ... openshift-oauth-apiserver-654477d69c-26r77 2/2 Running 0 4h36m 10.128.2.20 ... openshift-oauth-apiserver-654477d69c-m7llg 2/2 Running 0 4h36m 10.131.0.41 ... $ oc exec -it -n clusters-$HC_NAME --kubeconfig $MGMT_KUBECONFIG -c kube-apiserver kube-apiserver-596dcb97f-n5nqn -- bash bash-5.1$ curl -k -I https://172.30.18.228:443/apis/user.openshift.io/v1 HTTP/2 403 ... bash-5.1$ curl -k -I https://10.129.2.20:8443/healthz HTTP/2 200 ... bash-5.1$ curl -k -I https://10.128.2.20:8443/healthz HTTP/2 200 ... bash-5.1$ curl -k -I https://10.131.0.41:8443/healthz HTTP/2 200
Actual results:
Step 3: hit above False apiservices.
Expected results:
We know this may be expected, given the cluster already configures external OIDC. However, displaying "False (FailedDiscoveryCheck)" can leads to user confusion. Thus, we'd better handle it in better way without user confusion.
Additional info:
- is related to
-
OCPSTRAT-933 Hypershift guest cluster can use external OIDC token issuer
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
[OCPBUGS-30028] [Documents] Document "FailedDiscoveryCheck" apiservice issue is expected and can be avoided by ensuring external OIDC is configured at the time when the HostedCluster is created instead of configured after it is created
If day-2 enablement is not supported, it'd be great if we could either document or programmatically stop users from doing this.
fxierh, your OCPBUGS-30424 is due to OCPBUGS-30028. sjenning says "Setting it after creation is not supported" in above comment.
fxierh, could you try again setting external OIDC when creating your hosted cluster?
sjenning, do we need to re-consider in design to make it supported, due to fxierh's OCPBUGS-30424 ? CC atelang@redhat.com , azaalouk
sjenning , thanks for confirmation! I'd prefer it is worthy to document your point in our documents, because users or customers may not be aware of it. So I reopen it, and move this Jira to be a document tracker under OSDOCS-8106.
Seth Jennings
added a comment - If external OIDC is going to be used, type: OIDC must be set on the Authentication config at hosted cluster creation time. Setting it after creation is not supported, due to conversion and clean-up issues like this.
I did confirm that if you set `type: OIDC` at create time, these apiservices do not exist.
Seth Jennings
added a comment - If external OIDC is going to be used, type: OIDC must be set on the Authentication config at hosted cluster creation time. Setting it after creation is not supported, due to conversion and clean-up issues like this.
I did confirm that if you set `type: OIDC` at create time, these apiservices do not exist.
This bug is being closed because it has not had any activity in the past 3 months. While it represents a valid problem, leaving such bugs open provides a false indication that they will be addressed. Please reopen the bug if you have additional context that would help us better understand what needs to be done.