Have CVO maintain a ConfigMap containing the pullspec for the
baremetal-installer container image in the current release image.
We choose the baremetal-installer container because this is the one that
can run inside the cluster - the binary always matches the cpu architecture
of the container and it can run in FIPS mode.
Also include the machine-os-images pullspec in the ConfigMap, for future
flexibility in case it should be needed.
Currently the baremetal-installer container is included in the release
image by virtue of being referenced by the samples operator. However,
the samples operator is reportedly deprecated. Be more explicit by
labeling the container image (as the regular installer container is).
Starting with 4.19, the PATH environment variable is actively used
in CI to manage idempotent repositories that work both in CI as locally.
By overriding the PATH environment variable, machine-os-images gets
unfortunate repositories as a result. I suspect this path override can
just disappear.
Because of the way in which we rebase and build our kube fork, the
binary doesn't have minor versions set correctly. For example, version
1.29.5 appears as `v1.29.0-rc.1.3970+87992f48b0ead9-dirty` and that
breaks the version detection in our scripts.
Since we already have pre-built binaries in CI/release, there is no
reason for downloading those binaries. The only case in which it's
needed is for local dev. So we introduce an env var `SKIP_ENVTEST` to
skip the download when building images.
We copy pre-built binaries from the `-artifacts` images when we want
statically linked binaries and from the regular etcd/hyperkube images
for dynamically linked binaries.
This is necessary to have capi and capi providers included in the
installer images both for CI and for the release payload.
When we linked to libvirt directly, having the libvirt platform in the
build was synonymous with a dynamically linked build. Now that we use a
pure-Go libvirt library, the build type can be independent of whether
libvirt is included.
Once the baremetal installer build no longer includes the libvirt
platform, we still want it to be dynamically linked.
The baremetal-installer/libvirt-installer images continue being dynamically
built for FIPS support. For that reason it cannot reuse the existing
`terraform-providers` image. All other images will be statically built.
Since https://github.com/openshift/release/pull/39563 there should be
now an `installer-terraform-providers` image in the CI namespace with
pre-built terraform provider binaries. If no changes are detected from
the last time the providers were built, we skip building the providers
which can save us around 1h in the CI tests.
In https://github.com/openshift/enhancements/pull/679
we landed support for a stream metadata format already used
by FCOS and now by RHCOS/OCP consumers to find the bootimages.
We kept the old metadata because the UPI CI jobs used it.
In https://github.com/openshift/release/pull/17482 I tried
to port the UPI CI jobs, but ran into huge levels of technical debt.
As best I can tell, the UPI CI jobs are not running on this repo
now and are likely broken for other reasons.
Let's remove the old data and avoid the confusing duplication.
Anyone who goes to work on the UPI CI jobs and sanitizes things
should be able to pick up the work to port to stream metadata
relatively easily.
All installer binaries extracted from a payload, regardless of their
runtime OS or architecture, are built on the payload architecture.
Therefore, GOHOSTARCH can be used to assume the cluster architecture for
which its payload was built. This is set through the Dockerfiles so that
manual builds of installer will continue to default to amd64.
The latest version of RHEL ships with libvirt 6.x, which are now in
yum repositories used to build the CI containers. However, when running
an installer built that's linked against it on an older RHEL host, the
installer fails:
```
$ ocp/ostest/openshift-baremetal-install --dir ocp/ostest --log-level=debug create manifests
ocp/ostest/openshift-baremetal-install: /lib64/libvirt.so.0: version
```LIBVIRT_5.2.0' not found (required by
ocp/ostest/openshift-baremetal-install)
[...snip...]
```
According to the [RHEL 8 ABI Guarantees](https://access.redhat.com/articles/rhel8-abi-compatibility),
"an application is only guaranteed to run correctly if it executes in an
environment that is as new as the environment it was built in or newer."
Therefore, we must build openshift baremetal installer against the
oldest version of the libvirt libraries we expect it to run against,
which is 4.5.x.
Long term, the libvirt team is looking at not linking to libvirt at
compile time, but rather use `dlopen("libvirt.so")` at runtime, and then
`dlsym("funcname")` to resolve functions at time they are first invoked.
This PR is autogenerated by the [ocp-build-data-enforcer][1].
It updates the base images in the Dockerfile used for promotion in order to ensure it
matches the configuration in the [ocp-build-data repository][2] used
for producing release artifacts.
Instead of merging this PR you can also create an alternate PR that includes the changes found here.
If you believe the content of this PR is incorrect, please contact the dptp team in
#aos-art.
[1]: https://github.com/openshift/ci-tools/tree/master/cmd/ocp-build-data-enforcer
[2]: https://github.com/openshift/ocp-build-data/tree/openshift-4.6/images
With Go 1.14 the handling of modules has improved in the sense that all the subcommands `go {test, generate}` now use the vendor when available by default. This makes it easier for us to run generate using the vendored tools like controller-tools etc. as it now uses the checked in vendor.
