This commit teaches the completion function to repeat resource names
when supported by the command. The logic checks if a resource name
has already been specified by the user and does not include it again
when repeating the completion.
For example, the get command can receive multiple pods names, therefore
with this commit we have:
kubectl get pod pod1 [tab]
will provide completion of pod names again, but not show 'pod1' since
it is already part of the command-line.
The improvement affects the following commands:
- annotate
- apply edit-last-applied
- apply view-last-applied
- autoscale
- delete
- describe
- edit
- expose
- get
- label
- patch
- rollout history
- rollout pause
- rollout restart
- rollout resume
- rollout undo
- scale
- taint
Note that "rollout status" only accepts a single resource name, unlike
the other "rollout ..." commands; this required the creation of a
special completion function that did not repeat just for that case.
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
* [PodSecurity] Aggregate identical warnings for multiple pods in a namespace
* Make warning order deterministic, limit accumulated pod name data
Co-authored-by: njuptlzf <li.zhifeng@zte.com.cn>
Copying from pvcBlock swapped name and namespace (breaking the PVC test case)
and some references to the pvcBlock variable were left unchanged (incorrect
annotations for test failures).
Add a e2e test to exercise the checkpoint recovery flow.
This means we need to actually create a old (V1, pre-1.20) checkpoint,
but if we do it only in the e2e test, it's still fine.
Signed-off-by: Francesco Romani <fromani@redhat.com>
The commit a8b8995ef2
changed the content of the data kubelet writes in the checkpoint.
Unfortunately, the checkpoint restore code was not updated,
so if we upgrade kubelet from pre-1.20 to 1.20+, the
device manager cannot anymore restore its state correctly.
The only trace of this misbehaviour is this line in the
kubelet logs:
```
W0615 07:31:49.744770 4852 manager.go:244] Continue after failing to read checkpoint file. Device allocation info may NOT be up-to-date. Err: json: cannot unmarshal array into Go struct field PodDevicesEntry.Data.PodDeviceEntries.DeviceIDs of type checkpoint.DevicesPerNUMA
```
If we hit this bug, the device allocation info is
indeed NOT up-to-date up until the device plugins register
themselves again. This can take up to few minutes, depending
on the specific device plugin.
While the device manager state is inconsistent:
1. the kubelet will NOT update the device availability to zero, so
the scheduler will send pods towards the inconsistent kubelet.
2. at pod admission time, the device manager allocation will not
trigger, so pods will be admitted without devices actually
being allocated to them.
To fix these issues, we add support to the device manager to
read pre-1.20 checkpoint data. We retroactively call this
format "v1".
Signed-off-by: Francesco Romani <fromani@redhat.com>
