-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use k8s keychain first #1346
use k8s keychain first #1346
Conversation
This speeds up instances where the credentials are in image pull secrets
k8s, | ||
authn.DefaultKeychain, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
k8s, | |
authn.DefaultKeychain, | |
authn.DefaultKeychain, | |
k8s, |
I think we may still want the default keychain first, and it should at least be much quicker than the others, barring any cred helper shenanigans.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok with that .
Just be aware that if you're testing k8schain (pulling from creds from secrets) and you're hitting a real cluster you'll want to docker logout
beforehand :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nvm, I think I'm becoming convinced that k8s belongs first, since it eliminates the issue with slow cred helpers and potential confusion with local testing. Let's keep k8s
first. (Sorry for the review churn)
60a1755
to
ba384b3
Compare
ok k8s is first now |
This speeds up instances where the credentials are in image pull secrets