Skip to content
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

Merged
merged 3 commits into from
Mar 16, 2022

Conversation

pebrc
Copy link
Collaborator

@pebrc pebrc commented Mar 10, 2022

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.

@pebrc pebrc added >bug Something isn't working v2.2.0 labels Mar 10, 2022
Copy link
Contributor

@naemono naemono left a 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)
Copy link
Contributor

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?

Copy link
Collaborator Author

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?

Copy link
Collaborator Author

@pebrc pebrc Mar 16, 2022

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

pebrc and others added 2 commits March 14, 2022 09:38
Co-authored-by: Thibault Richard <thbkrkr@users.noreply.github.com>
@pebrc pebrc merged commit f9f94c5 into elastic:main Mar 16, 2022
fantapsody pushed a commit to fantapsody/cloud-on-k8s that referenced this pull request Feb 7, 2023
…stic#5461)

Co-authored-by: Thibault Richard <thbkrkr@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug Something isn't working v2.2.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants