-
Notifications
You must be signed in to change notification settings - Fork 726
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
Avoid unnecessary DELETE calls to manage legacy transport secret #5461
Conversation
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.
lgtm; question though
}, | ||
var secret corev1.Secret | ||
// do a GET from the cache first before attempting a DElETE that hits the API server | ||
err := client.Get(context.Background(), types.NamespacedName{Namespace: es.Namespace, Name: esv1.LegacyTransportCertsSecretSuffix(es.Name)}, &secret) |
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.
Question, not an issue, but why do we use context.Background()
throughout the codebase for kubernetes client.* calls instead of something with a default timeout?
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 think that's a valid question maybe raise a separate issue to discuss it though?
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.
FWIW #5450 indicates that a 1m service side timeout parameter is applied to all requests
pkg/controller/elasticsearch/certificates/transport/reconcile.go
Outdated
Show resolved
Hide resolved
Co-authored-by: Thibault Richard <thbkrkr@users.noreply.github.com>
…stic#5461) Co-authored-by: Thibault Richard <thbkrkr@users.noreply.github.com>
Related to #5450
This PR proposes to do a GET (from cache) before DELETE to minimise impact on the API server. Alternative approach I could think of is to track the deletion in the orchestration hints annotation but that seemed costly/complicated compared to the almost free GET request.