we should only use this env var for `arm`, since `arm64` is fully
supported by etcd folks, let us drop this!
(ex - https://github.com/etcd-io/etcd/releases/tag/v3.5.6)
ppc64le comment should be dropped as well
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
This was used by migrate-if-needed.sh, but that has been replaced by
the migrate Go program which doesn't need external cp.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Writing file first truncate it and writes later on. During disk space pressure it may cause file to become empty. To mitigate above, we create file with new version first and then move it in place of old one (to make sure that disk space is available)
We can use docker buildx in order to build and push Windows images from the same Linux node,
as long as the Dockerfile does not have any RUN commands in the Windows step.
We also need to create a non-default builder instance in order to be able to build and
push Windows images.
The Windows images have to be built and pushed directly to the registry.
For Windows containers without Hyper-V isolation, the host OS Version and the
Container OS Version need to match, which is why we added multiple Windows OS Versions
to the building process.
For the manifest list, we need to also annotate the Windows OS Version, so the Windows nodes
will be able to pull the proper image from the manifest list.
Adds support for Windows OS Versions: 1809, 2004, 20H2, ltsc2022.
Bumped etcd image revision.
The --log-file parameter will be deprecated as of Kubernetes 1.23 and should be
avoided. The replacement for distroless images is the image with go-runner, a
tool that handles output redirection.
For kubemark to run in that image it must be built as static binary.
This allows to choose the correct architecture in the image manifest,
which defaulted to the host system before applying this patch.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
We can use docker buildx in order to build and push Windows images from the same Linux node,
as long as the Dockerfile does not have any RUN commands in the Windows step.
We also need to create a non-default builder instance in order to be able to build and
push Windows images.
The Windows images have to be built and pushed directly to the registry.
For Windows containers without Hyper-V isolation, the host OS Version and the
Container OS Version need to match, which is why we added multiple Windows OS Versions
to the building process.
For the manifest list, we need to also annotate the Windows OS Version, so the Windows nodes
will be able to pull the proper image from the manifest list.
Adds support for Windows OS Versions: 1809, 2004, 20H2, ltsc2022.
Bumped etcd image revision.
