Rewrite the cpumanager tests to make use of the lessons
learned, more modern idioms, remove obsolete assumptions
and in gneeral remove all the legacy which was accumulating
over the years.
The goal is to have a simpler, flatter and more maintenable
code layout, de-entangle the net of dependency,
making the tests more robust and easier to extend.
In short, this is all about maintainability. All the testcases
will be preserved, and few other can be added along the way.
Comments in the code will explain the code layout decisions
and tradeoff, and provide a good guide to add more tests
in the future.
Special care was added in order to maximize the isolation between
tests, at cost, in selected cases of a controlled and planned
code duplication.
Signed-off-by: Francesco Romani <fromani@redhat.com>
Passing a constant value to gomega.Consistently means that it will not re-check
while running.
Found by linter after removing the suppression rule for the check. It was
disabled earlier because of a bug in the linter.
This fixes the pod with restartable init containers to have a proper
phase after the pod sandbox re-creation.
Currently, the `runtime.PodStatus` cannot retrieve the active container
statuses, which are the container statuses associated with the current
pod sandbox. This adds the `ActiveContainerStatuses` to
`runtime.PodStatus`, allowing it to include the container statuses of
the current pod sandbox, and fixes the kubelet to correctly set the pod
Phase to `Pending` when no active regular containers are present.
When supporting rolling updates, we cannot use the same fixed socket paths for
old and new pod. With the revised API, the caller no longer specifies the full
socket paths, only directories. The logic about how to name sockets then can be
in the helper.
While at it, avoid passing a context to the gRPC helper code when
all that the helper code needs is a logger. That leads to confusion
about whether cancellation has an effect.
add missing metric about uncore / L3 / Last-Level cache alignment,
plus its e2e tests.
Exposing uncore alignment requires a bit of refactoring in the static
policy implementation because, differently from full PCPUs alignment
and NUMA alignment, can't be easily and safely inferred by construction.
The main reason for this is that uncore cache alignment is preferred,
not mandatory, thus the cpu allocator can legally use cross-uncore
allocation. Because of that, the final cpuset union step can
create a final cpuset which is not uncore-aligned even though all
its parts are uncore-aligned.
The safest way seems thus to run just a final uncore-alignment check
once the final cpuset is computed.
Signed-off-by: Francesco Romani <fromani@redhat.com>
