-
Notifications
You must be signed in to change notification settings - Fork 1.8k
only preload local cluster cas #48483
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
Conversation
This pull request is automatically being deployed by Amplify Hosting (learn more). |
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.
Sorry for duplicate comments, but I somehow managed to mishandle them: Consider also updating the watchForCAChanges
documentation comment, as it's now outdated.
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.
Approving because the PR description and the code seem to make sense, though I know very little about how we handle CAs.
4d7bf1f
to
5c96d26
Compare
5c96d26
to
3eca95b
Compare
@fspmarshall See the table below for backport results.
|
The original implementation of the client TLS config generator tried to always pre-generate all TLS configs for all known CAs on all changes. This was nice in theory, but created spurious error logs due to remote clusters not having all requisite CAs stored, and was wasted effort in many cases.
This PR tweaks the event-handling logic of the client TLS config generator to only aggressively generate TLS configs in response to modification events for the local cluster. For all other clusters, it invalidates any now stale state, but waits until a connection actually comes in before nothing to try to build the TLS config.
Fixes #48331