-
Notifications
You must be signed in to change notification settings - Fork 40.9k
Migrate devicemanager to context logging (1/5) #132540
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
base: master
Are you sure you want to change the base?
Conversation
|
Welcome @chuangw6! |
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Hi @chuangw6. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/ok-to-test |
2986644
to
36d6bfa
Compare
/retest |
4eea21f
to
b32e789
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: chuangw6 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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.
thanks for the PR! I'm generally very supportive of moving to contextual logging (and my own effort starved). I expect a somehow long tail of tuning and refinements after the initial plumbing lands, but by all means let's get the plumbing merged before!
Some comments inside
Connect(ctx context.Context) error | ||
Run(ctx context.Context) | ||
Disconnect(ctx context.Context) error |
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.
not sure we can just the method signature of the interface, will check
@@ -307,7 +307,7 @@ func (pm *DRAPluginManager) get(driverName string) *DRAPlugin { | |||
// name>" format (e.g. "v1beta1.DRAPlugin"). This allows kubelet to determine | |||
// in advance which version to use resp. which optional services the plugin | |||
// supports. | |||
func (pm *DRAPluginManager) RegisterPlugin(driverName string, endpoint string, supportedServices []string, pluginClientTimeout *time.Duration) error { | |||
func (pm *DRAPluginManager) RegisterPlugin(_ context.Context, driverName string, endpoint string, supportedServices []string, pluginClientTimeout *time.Duration) error { |
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.
uhm, devicemanager is not related to DRA. Why do we want to update also DRA code?
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.
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.
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.
can look into it when I am back to office (Thursday and Friday are U.S. holidays). A couple of questions:
#130376 doesn't plumb context to the interface in pkg/kubelet/pluginmanager/cache/types.go (validate, register, deregister), but the interface is used at many places as you may see in this PR including
- pkg/kubelet/cm/devicemanager/plugin/v1beta1/handler.go
- pkg/kubelet/pluginmanager/operationexecutor/operation_generator.go
- pkg/volume/csi/csi_plugin.go
I can ignore the last 2, but pkg/kubelet/cm/devicemanager/plugin/v1beta1/handler.go
is under the scope for migrating to context logging. Are you okay with using context.TODO()
instead of plumbing ctx for that file?
Circulating back to your comments in #132583, it's unclear to me what migration approach you are looking for. Seems like you're okay with this 1/5 PR except pluginmanager thing, but this 1/5 PR just migrates a portion of devicemanager. And there are so much more to migrate as described in the PR description. So can you please clarify what approach you are looking for for migrating other files in devicemanager if file-by-file approach is not ideal?
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 can ignore the last 2, but pkg/kubelet/cm/devicemanager/plugin/v1beta1/handler.go is under the scope for migrating to context logging. Are you okay with using context.TODO() instead of plumbing ctx for that file?
I'm ok with using context.TODO() with a comment explaining when and how it's going to be replaced with a proper context.
So can you please clarify what approach you are looking for for migrating other files in devicemanager if file-by-file approach is not ideal?
So far it was one PR for one component. You can see current migration status in the description of the issue #130069. If component is too big it makes sense to migrate it by more than one PR, but definitely not by one PR per file.
BTW, the approach is explained in the issue as well. If there is something not clear, please suggest better description.
func (h *RegistrationHandler) ValidatePlugin(pluginName string, endpoint string, versions []string) error { | ||
klog.Info(log("Trying to validate a new CSI Driver with name: %s endpoint: %s versions: %s", | ||
pluginName, endpoint, strings.Join(versions, ","))) | ||
func (h *RegistrationHandler) ValidatePlugin(ctx context.Context, pluginName string, endpoint string, versions []string) error { |
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.
likewise, are updating all plugins in one go or just device manager?
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.
My goal was to just update device manager, but to migrate pkg/kubelet/cm/devicemanager/plugin/v1beta1/handler.go, the PluginHandler
interface in pkg/kubelet/pluginmanager/cache/types.go needs to be updated. Otherwise, type check will fail. This led to a series of cascading changes.
nolint:errcheck |
/test pull-kubernetes-linter-hints |
/test pull-kubernetes-node-e2e-containerd |
@chuangw6: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
General note about migration to contextual logging. There are quite few areas where we can use or should use more contexts; that's fine. In general however just passing context around for the sake of using the logger instance (because this is only the legit use of the context in such cases) seems suboptimal. |
@ffromani Generally I agree with you, but it's tough to know if a function will need a context later or just a logger. If we only pass a logger and it ends up needing a context, that's an issue. |
As general approach to move to contextual logging, we can either very carefully review ewach and every PR and try to anticipate needs, adding context in the logs and evaluate on a case-by-case basis where we can use what, or do a series of sweeping changes. E.g.
I'm ok with a series of sweeping changes, so I'm ok with the general direction of this PR. We will review again. Please make sure to make and keep CI happy. |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
migrate pkg/kubelet/cm/devicemanager to contextual logging
Which issue(s) this PR is related to:
#130069
Special notes for your reviewer:
This PR migrated:
NewManagerImpl
,Start
andStop
in pkg/kubelet/cm/devicemanager/manager.goSorry for this PR's size. I fall down the rabbit hole of plumbing through context :<. I will migrate following files with smaller PRs:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: