kubectl wait command errors out when the waited resource does not exist.
But we need to provide a way to the users about intentionally also waiting for
the creation of resources.
This PR introduces a new flag to cover waiting for the creation of resources
with preserving the default behavior.
If we're following a file, that file will remain open, and we continue
to read data from it when new data becomes available.
On Windows, this can be an issue if the container logs needs to be rotated.
Log rotation is done by renaming the file, but this action may fail if
the file is already opened.
Setting the FILE_SHARE_DELETE flag when opening the file will prevent this
issue, as documented: "Delete access allows both delete and rename operations" [1].
In golang, there's no way to set this flag [2], the sharemode is always set to:
sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE)
Thus, we need to open the file ourselves with the right flags.
[1] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea?redirectedfrom=MSDN
[2] https://cs.opensource.google/go/go/+/refs/tags/go1.22.2:src/syscall/syscall_windows.go;l=366
The internal informer populates the RV as soon as it conducts
The first successful sync with the underlying store.
The cache must wait until this first sync is completed to be deemed ready.
Since we cannot send a bookmark when the lastProcessedResourceVersion is 0,
we poll aggressively for the first list RV before entering the dispatch loop.
When using GOTOOLCHAIN with make verify the build results copied out of
the dockerized environment contains a go toolchain folder that is
write protected. In order to prevent failures during the cleanup step
opt-out of copying $GOPATH to the host.
When doing a kubelet health check on init/join, do not
hardcode the "localhost" address. Instead, use the
KubeletConfiguration HealthzBindAddress and HealthzPort
fields.
Adds the KUBE_BUILD_WINDOWS option to make release-images and quick-release-images,
which will allow it to build the a Windows kube-proxy image as well. That image can
then be used with Windows Host Process Containers to start the kube-proxy
service on Windows nodes.
Be smarter about finding the input packages for genclient et al. The
previous grep patterns were too generic. This caused code-generator, for
example, to pick up it's own auto-generated packages. In this particular
case having a status field in the type adds a comment to the
autogenerated code like:
// Add a +genclient:noStatus comment above the type...
This, in turn causes problems in some scenarios where the input (api)
and the target package for the auto-generated code reside in separate go
modules.
