Bug 1625776
| Summary: | Admin console does not report failures when OAuth discovery fails | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Justin Pierce <jupierce> |
| Component: | Management Console | Assignee: | Samuel Padgett <spadgett> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Yadan Pei <yapei> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.11.0 | CC: | aos-bugs, jokerman, mmccomas, spadgett, yapei |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | 3.11.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: | 2018-09-17 13:13:01 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: | |||
|
Description
Justin Pierce
2018-09-05 20:30:01 UTC
We probably want to default to error rather than info to avoid noise in the logs. (In reply to Samuel Padgett from comment #2) > https://github.com/openshift/console/pull/498 498 has been replaced by https://github.com/openshift/console/pull/506 How could we mock the failure to see if admin console pods give enough logs? The easiest way I know is to run off-cluster with an invalid `k8s-mode-off-cluster-endpoint` value. It's harder to test on-cluster since it should not be possible to configure incorrectly, although it would fail if the API server can't be reached from the container. 1. cd /path/to/console & git pull latest code 2. export OPENSHIFT_API="https://127.0.0.1:8446" 3. Run bridge in off-cluster mode, we could see error info printed $ ./examples/run-bridge.sh 2018/09/11 13:59:44 cmd/main: cookies are not secure because base-address is not https! 2018/09/11 13:59:44 auth: error contacting openid connect provider (retrying in 2s): Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 13:59:46 auth: error contacting openid connect provider (retrying in 4s): Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 13:59:50 auth: error contacting openid connect provider (retrying in 8s): Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 13:59:58 auth: error contacting openid connect provider (retrying in 16s): Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 14:00:14 auth: error contacting openid connect provider (retrying in 32s): Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 14:00:46 auth: error contacting openid connect provider: Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 14:00:46 cmd/main: Error initializing OIDC authenticator: Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused Then I reset to a commit which doesn't contain fix PR "#506" $ git reset --hard 6a062bc7da88d3aa38bd7b44dd1fe9150dfabb1c HEAD is now at 6a062bc7d Merge pull request #502 from rhamilto/console-54 $ git log --pretty="%h %cd - %s" | grep '#506' (doesn't container our #506) 8c767904d Thu Mar 3 09:50:49 2016 -0800 - Merge pull request #506 from coreos-inc/have-curl-around-just-in-case And repeat step2 - 3 above, I also got the same errors as above. ./examples/run-bridge.sh 2018/09/11 14:06:19 cmd/main: cookies are not secure because base-address is not https! 2018/09/11 14:06:19 auth: error contacting openid connect provider (retrying in 2s): Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 14:06:21 auth: error contacting openid connect provider (retrying in 4s): Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 14:06:25 auth: error contacting openid connect provider (retrying in 8s): Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 14:06:33 auth: error contacting openid connect provider (retrying in 16s): Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 14:06:49 auth: error contacting openid connect provider (retrying in 32s): Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 14:07:21 auth: error contacting openid connect provider: Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused 2018/09/11 14:07:21 cmd/main: Error initializing OIDC authenticator: Get https://127.0.0.1:8446/.well-known/oauth-authorization-server: dial tcp 127.0.0.1:8446: connect: connection refused In both conditions, err info is printed as code: log.Errorf("error contacting openid connect provider (retrying in %s): %v", backoff, err) Hi Sam, could you help confirm if this is what we expect? IMO it should not. Did you run `./build-backend.sh` after changing commits? You need to rebuild the Go code to test. You're right, after resetting commit and run ./build.sh, the error info is different $ git reset --hard 2e53f3c102eec5821d94b65fa75a72b0ee50f805 $ ./build.sh $ export OPENSHIFT_API="https://127.0.0.1:8446" $ ./examples/run-bridge.sh 2018/09/12 10:47:23 cmd/main: cookies are not secure because base-address is not https! 2018/09/12 10:47:23 cmd/main: Binding to 127.0.0.1:9000... 2018/09/12 10:47:23 cmd/main: not using TLS error info is not printed So I will verify the bug based on comparison between old and current behavior *** Bug 1628573 has been marked as a duplicate of this bug. *** yapei - can you verify that the admin console login works correctly on a 3.10 -> 3.11 upgrade? The upgrade itself previously wouldn't fail because of this bug, but login didn't work. This was the original problem we were trying to fix, so it would be good to validate that scenario. See discussion in bug 1628573. Sam, upgrade testing is blocked by bug 1628730, will give another try once upgrade blocker is fixed |