The container status waiting reason toggles between `ImagePullBackOff`
and the actual pull error, resulting in a bad user experience for
consumers like kubectl. For example, the output of
`kubectl get pods` does return either:
```
NAME READY STATUS RESTARTS AGE
pod 0/1 SignatureValidationFailed 0 10s
```
or
```
NAME READY STATUS RESTARTS AGE
pod 0/1 ImagePullBackOff 0 18s
```
depending in which state the image pull is. We now improve that behavior
by preserving the actual error in the `message` of the `waiting` state
from the pull during back-off:
```json
{
"waiting": {
"message": "Back-off pulling image \"quay.io/crio/unsigned:latest\": SignatureValidationFailed: image pull failed for quay.io/crio/unsigned:latest because the signature validation failed: Source
image rejected: A signature was required, but no signature exists",
"reason": "ImagePullBackOff"
}
}
```
While the `SignatureValidationFailed` value inherits from the previous
known state:
```json
{
"waiting": {
"message": "image pull failed for quay.io/crio/unsigned:latest because the signature validation failed: Source image rejected: A signature was required, but no signature exists",
"reason": "SignatureValidationFailed"
}
}
```
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
on None cpumanager policy, cgroupv2, and systemd cgroup manager, kubelet
could get into a situation where it believes the cpuset cgroup was created
(by libcontainer in the cgroupfs) but systemd has deleted it, as it wasn't requested
to create it. This causes one unnecessary restart, as kubelet fails with
`failed to initialize top level QOS containers: root container [kubepods] doesn't exist.`
This only causes one restart because the kubelet skips recreating the cgroup
if it already exists, but it's still a bother and is fixed this way
Signed-off-by: Peter Hunt <pehunt@redhat.com>
Fix error message if availablePhysicalCPUs = 0.
Without this change, the logic was mistakenly emitting
the old error message, which is confusing for troubleshooting.
Plus, a tiny quality of life improvement:
cpumanager static policy wants to use `cpuGroupSize` multiple times.
The value represents how many VCPUs per PCPUs the machine has.
So, let's cache (and log!) the value in the policy data.
We don't support dynamic update of the HW topology anyway.
Signed-off-by: Francesco Romani <fromani@redhat.com>
this change removes the deprecation warning function in favor of using
the `cloudprovider.DisableWarningForProvider`. it also fixes some of the
logic to ensure that non-external providers are properly detected and
warned about.
The internal cloud controller loops are disabled at this point, this
function should not be used as it does not return accurate information.
In its place we check for the presence of the external cloud provider as
that is the only acceptable value.
