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

Do not use context.Background() on write requests to the k8s API #5649

Merged
merged 6 commits into from
May 17, 2022

Conversation

pebrc
Copy link
Collaborator

@pebrc pebrc commented May 8, 2022

This is preparatory work for #5467

It introduces the correct context into all requests made with the k8s client-go library that do not use the cache. So the rule is

  • Create, Update, Delete need a correct context
  • List, Get do not because the cached client dismisses the context argument anyway. I added one where it was in scope but did not do additional refactoring to introduce one where there was no context in scope.

The main motivation for the distinction between reads and writes is to limit scope of the refactoring somewhat.

This will allow us in a next step to add tracing for k8s client requests (sneak preview of how that will look like):
Screenshot 2022-05-09 at 17 13 56

Note for reviewers

This is probably bit of a nightmare to review given the repetitive nature of the change and large change set. Things of interest to focus on could be:

  • I made changes to the asyncTasks that are run from the manager/main.go to introduce context and start transactions. This probably worth a closer look and also worth following into the individual tasks like the license info reporter and the telemetry reporter etc.
  • test code is probably less interesting as it just adds contexts where I changed function signatures

@botelastic botelastic bot added the triage label May 8, 2022
@botelastic botelastic bot removed the triage label May 8, 2022
@pebrc pebrc changed the title Introduce context where missing Do not use context.Background() on write requests to the k8s API May 8, 2022
@pebrc
Copy link
Collaborator Author

pebrc commented May 9, 2022

Jenkins test this please

@pebrc pebrc marked this pull request as ready for review May 9, 2022 12:41
@pebrc pebrc added the v2.3.0 label May 12, 2022
Copy link
Contributor

@thbkrkr thbkrkr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

gcCtx := tracing.NewContextTransaction(ctx, tracer, "garbage-collection", "on_operator_start", nil)
err := garbageCollectUsers(gcCtx, cfg, managedNamespaces)
if err != nil {
log.Error(err, "user garbage collector failed")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: we are going to log twice user garbage collector failed:

  2022-05-17T10:09:35.427+0200    ERROR   manager user garbage collector failed {
    "service.version": "2.3.0-SNAPSHOT+6b671559",
    "error": "user garbage collector creation failed: root_error_message"
  }
Suggested change
log.Error(err, "user garbage collector failed")
log.Error(err)

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 method signature does not exist but I can adjust the message a bit to avoid the repetition.

@pebrc pebrc merged commit 2ad78d1 into elastic:main May 17, 2022
@thbkrkr thbkrkr mentioned this pull request Jun 8, 2022
fantapsody pushed a commit to fantapsody/cloud-on-k8s that referenced this pull request Feb 7, 2023
…stic#5649)

Introduces the correct context into all requests made with the k8s client-go library that do not use the cache. So the rule is: Create, Update, Delete need a correct context. List, Get do not because the cached client dismisses the context argument anyway. I added one where it was in scope but did not do additional refactoring to introduce one where there was not context in scope. The main motivation for the distinction between reads and writes is to limit scope of the refactoring somewhat.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants