We are not sure why this was stdout, since stdin is what the user uses to pass
information to the exec plugin.
There is a question of backwards compatibility here. Our take is that this is a
bug, and so we are ameliorating behavior instead of breaking behavior. There are
2 main cases to consider with respect to backwards compatibility:
1. an existing exec plugin depended on stdin being hooked up to them if stdout
was a terminal (e.g., echo foo | client-go-command-line-tool); we believe
this is an anti-pattern, since the client-go-command-line-tool could be using
stdin elsewhere (e.g., echo foo | kubectl apply -f -)
2. an existing exec plugin depended on stdin not being hooked up to them if
stdout was not a terminal (e.g., client-go-command-line-tool >/dev/null);
hopefully there are very few plugins that have tried to base logic off of
whether stdin returned EOF immediately, since this could also happen when
something else is wrong with stdin
We hope to apply a stronger fix to this exec plugin user interaction stuff in a
future release.
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
This updates the EndpointSlice controller to make use of the
EndpointSlice tracker to identify when expected changes are not present
in the cache yet. If this is detected, the controller will wait to sync
until all expected updates have been received. This should help avoid
race conditions that would result in duplicate EndpointSlices or failed
attempts to update stale EndpointSlices. To simplify this logic, this
also moves the EndpointSlice tracker from relying on resource versions
to generations.
The `apparmor_parser` binary is not really required for a system to run
AppArmor from a Kubernetes perspective. How to apply the profile is more
in the responsibility of lower level runtimes like CRI-O and containerd,
which may do the binary check on their own.
This synchronizes the current libcontainer implementation with the
vendored Kubernetes source code and allows distributions to use
AppArmor, even when they do not have the parser available in
`/sbin/apparmor_parser`.
Signed-off-by: Sascha Grunert <mail@saschagrunert.de>
Right now, there is no way to use these annotations, support multiple
`kubectl` versions, and not give users annoying warnings every time they
run `kubectl log`.
If a user is setting *both* annotations, they clearly know that the old
on is deprecated. Therefor, we should not warn them.
