add cpumanager to contextual logging linter
regenerate with
```hack/update-golangci-lint-config.sh```
Signed-off-by: Francesco Romani <fromani@redhat.com>
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>
- Updated base image from python:3.6-slim-stretch to python:3.11-slim-bookworm
- Bumped version from 1.3 to 1.4
- Updated TensorFlow from 1.9.0 to 2.20.0 (latest stable)
- Updated TensorFlow models from v1.9.0 to v2.15.0
Signed-off-by: Humble Devassy Chirammal <humble.devassy@gmail.com>
For historic reasons kubeadm kept track of a skew of 2+
etcd version in a map in the constants.go file.
This is really not required because kubeadm supports only
2 version of etcd mapped to two Kubernetes versions,
which are essentially the control plane versions.
Refactor the constants.go map to only include 2 versions.
Make sure that's reflected in a unit test.
Instead of pinning the versions as literal numbers,
start using the version we get on build time.
Adapt various unit tests and functions to allow this change
to work, since during unit tests we need actual values
and the build versions are not populated. This is achieved
by requiring the functions to accept a map[uint8]string
used for testing.
kube::test::if_has_string and kube::test::if_has_not_string only match
the first argument, and don't allow regular expressions, so we need to
split the checks into separate buckets, ensuring they are strictly tied
to this particular test.
Signed-off-by: Maciej Szulik <soltysh@gmail.com>
By using k8s.io/system-validators v1.12.1 a KubeletVersion
can be passed to the CgroupsValidator. The library
can then decide if to throw an error or a warning.
An error is thrown if the version is >= 1.35.
During upgrade pass a KubeletVersion that is with MINOR+1
to account for the target upgrade version. That is just
an assumption that the user will upgrade the kubelet too,
but it is better to throw an error for this
common use case instead of just a warning that is seen
after the upgrade command has finished.
