mirror of
https://github.com/k3s-io/kubernetes.git
synced 2026-02-22 07:03:28 +00:00
fd5b2efa76
migrate the cpumanager code to contextual logging design musings: - golang contexts "[...] carries deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes." (see: https://pkg.go.dev/context#pkg-overview). Thus, it generally makes sense to add contexts to most of the APIs and functions as the resource management is done in the admission flow, when ultimately we process a request and we have time bounds; - however, receiving a context from the outside and depending on it kind also conflicts with the goal of having uniform logging and " - attach key/value pairs that get included in all log messages - add names that describe which component or operation triggered a log messages" (see: https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging#summary) Some of this conflict is due to the transitional nature of the PRs which we do when updating the codelet codebase. We can envision a final state on which the top level caller adds identifying information like pod UID and pod namespace/name pair; but up until all the calling chain is updated and wired, the results are gonna be inconsistent. - continuing from the point above, the most realistic transition plan for the kubelet is outlined in https://github.com/kubernetes/kubernetes/issues/130069 . Since we do want to move in parallel and migrate on a subsystem-by-subsystem basis, each subsystem will be in charge to add the data they want to their contexts. I think this is the only reasonnable way forward, and the cost will be overhead and redundancy. We should do sweeping changes to uniform the flows once we completed the full transition to ensure uniformity. - there are some well known packages which want to operate by design only in in-memory data structure, which arguably can't block. Shoehorning a context feels not great. Instead, we intentionally pass only the logger, which still is the core idea of contextual logging (see: https://github.com/kubernetes/kubernetes/pull/125912#discussion_r1935919144) examples are the topology subpackage and the cpu_assignment logic (takeByTopology and friends) Signed-off-by: Francesco Romani <fromani@redhat.com>