Wait for authenticators to be initialized#4122
Conversation
The authenticators do have a healthcheck, however this healthcheck is not exposed and it is not easy to expose without intrusive changes. An alternative would've been to use the update function returned by kubeAuthConfig.New which _does_ wait until the authenticator's healthcheck are ready, however that would create each authenticator twice and just discard the first iteration. Instead the authenticator is validated by continually authenticating a dummy token created with the first issuer until the error is no longer "not initialized". Signed-off-by: Nelo-T. Wallus <red.brush9525@fastmail.com> Signed-off-by: Nelo-T. Wallus <n.wallus@sap.com>
560c984 to
e0c0e61
Compare
|
/cherry-pick release-0.31 |
|
@ntnn: once the present PR merges, I will cherry-pick it on top of DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
LGTM label has been added. DetailsGit tree hash: 63c6e66a7890849fdcc9b8b510e65cea4ecbe9c8 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mjudeikis The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@ntnn: new pull request created: #4123 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Summary
The authenticators do have a healthcheck, however this healthcheck is not exposed and it is not easy to expose without intrusive changes.
An alternative would've been to use the update function returned by kubeAuthConfig.New which does wait until the authenticator's healthcheck are ready, however that would create each authenticator twice and just discard the first iteration.
Instead the authenticator is validated by continually authenticating a dummy token created with the first issuer until the error is no longer "not initialized".
What Type of PR Is This?
/kind bug
/cherry-pick release-0.31
Related Issue(s)
Fixes #4115
Release Notes