The changes done here will update the RHCOS 4.19 bootimage metadata and
address the following issues:
OCPBUGS-64612: [4.19] coreos-boot-disk link not working with multipath on early boot
OCPBUGS-67202: [4.19] Cannot use auto-forward kargs (like ip=) with coreos-installer (iso|pxe) customize
OCPBUGS-68357: [4.19] Using multipath on the sysroot will fail to boot if less than 2 paths are present
OCPBUGS-69838: [4.19] Ignition fails with crypto/ecdh: invalid random source in FIPS 140-only mode
This change was generated using:
plume cosa2stream \
--target data/data/coreos/rhcos.json \
--distro rhcos \
--no-signatures \
--name rhel-9.6 \
--url https://rhcos.mirror.openshift.com/art/storage/prod/streams \
x86_64=9.6.20260112-0 \
aarch64=9.6.20260112-0 \
s390x=9.6.20260112-0 \
ppc64le=9.6.20260112-0
Signed-off-by: Tiago Bueno <tiago.bueno@gmail.com>
Installations using ABI/assisted with 16GiB of RAM on the bootstrap node
were failing with "no space left on device" during bootstrapping. The
live ISO environment uses a tmpfs mounted at /var that is sized at 50%
of available RAM. On systems with 16GiB of RAM, this provides only 8GiB
of tmpfs space.
At the beginning of the bootstrap process, node-image-pull.sh creates an
ostree checkout underneath /var/ostree-container. When this is added to
the regular disk space usage of the later parts of the bootstrap, the
peak tmpfs usage hits around 9.4GiB.
This fix creates a separate 4GiB tmpfs for /var/ostree-container, so
that it is not subject to the limits on the size of /var.
The changes done here will update the RHCOS 4.19 bootimage metadata and
address the following issues:
OCPBUGS-64612: [4.19] [OCP 4.18] coreos-boot-disk link not working with
multipath on early boot
This change was generated using:
plume cosa2stream \
--target data/data/coreos/rhcos.json \
--distro rhcos \
--no-signatures \
--name rhel-9.6 \
--url https://rhcos.mirror.openshift.com/art/storage/prod/streams \
x86_64=9.6.20251113-0 \
aarch64=9.6.20251113-0 \
s390x=9.6.20251113-0 \
ppc64le=9.6.20251113-0
Signed-off-by: Tiago Bueno <tiago.bueno@gmail.com>
The changes done here will update the RHCOS 4.19 bootimage metadata and
address the following issues:
OCPBUGS-62699: Revert inclusion of AWS ECR credential provider in RHEL layer
This change was generated using:
```
plume cosa2stream --target data/data/coreos/rhcos.json \
--distro rhcos --no-signatures --name rhel-9.6 \
--url https://rhcos.mirror.openshift.com/art/storage/prod/streams \
x86_64=9.6.20251023-0 \
aarch64=9.6.20251023-0 \
s390x=9.6.20251023-0 \
ppc64le=9.6.20251023-0
```
The changes done here will update the RHCOS 4.19 bootimage metadata and
address the following issues:
COS-3042: GA ROSA-HCP support Windows LI for CNV
This change was generated using:
```
plume cosa2stream --target data/data/coreos/rhcos.json \
--distro rhcos --no-signatures --name rhel-9.6 \
--url https://rhcos.mirror.openshift.com/art/storage/prod/streams \
x86_64=9.6.20251015-1 \
aarch64=9.6.20251015-1 \
s390x=9.6.20251015-1 \
ppc64le=9.6.20251015-1
```
With multi-node installations the settings for /var/lib/etcd are
0700. This should be the same from SNO but the bootstrap-in-place
ignition is setting it to 0755.
* pkg/asset/manifests: add MCO operator manifest
Adds manifest generation for MCO configuration.
Currently the manifest is only generated when
custom boot images are specified, in order
to disable MCO management of those boot images.
The manifest generation uses a golang template
as testing revealed that API server validation
would not permit the manifests generated from
serializing the golang structs, which would
be more consistent with how we generate manifests
for other openshift operators. As golang will
populate the zero value for any non-pointer struct
this triggered validation, where the API server
expected certain required fields for these zero-value
structs. Using a template allows us to bypass this
problem.
Fixes OCPBUGS-57348
* fixup! pkg/asset/manifests: add MCO operator manifest
* fixup! pkg/asset/manifests: add MCO operator manifest
---------
Co-authored-by: Patrick Dillon <padillon@redhat.com>
The changes done here will update the RHCOS 4.19 bootimage metadata.
Notable changes in the boot image are:
- OCPBUGS-56600: The toolbox package built in rhcos-9.6.20250514-0 can't work
This change was generated using:
```
plume cosa2stream --target data/data/coreos/rhcos.json \
--distro rhcos --no-signatures --name rhel-9.6 \
--url https://rhcos.mirror.openshift.com/art/storage/prod/streams \
x86_64=9.6.20250523-0 \
aarch64=9.6.20250523-0 \
s390x=9.6.20250523-0 \
ppc64le=9.6.20250523-0
```
For the Azure identity API, the installer makes use directly of the
CAPZ API, but we do add validation to not support SystemAssigned
identities.
SystemAssigned identities were removed in
11f006d
but I missed updating the godoc text which is pulled in from CAPZ.
This PR updates the godoc text and kubebuilder annotations so that the
explain command will not show SystemAssigned identities as a valid choice.
Also the godoc text indicated identity was for control-plane only; fixed
to include compute.
https://github.com/openshift/installer/pull/9538 switched the installer
to not create user-assigned identities for VMs, and exposed an API
for users to bring-their-own identities and attach them to nodes.
OCPBUGS-56008 shows that the kubelet still depends on the node
identity to pull images from Azure Container Registry (ACR). To
resolve this issue, this commit sets the default back to using
an installer-generated identity attached to the node. The API is
still exposed in the install config, so users who do not utilize
ACR can set the identity type to None and install with less privileged
credentials.
When upstream work lands to allow these credentials to be managed
via credentialsrequests, we can go set the default identity to None
and remove the logic for creating identities. The upstream work
is tracked here and looks like it should be available in the next
release:
https://github.com/kubernetes/enhancements/issues/4412
Two Node OpenShift (TNF) is DevPreview in 4.19. In order to ensure that ironic doesn't try to manage
the power state of the nodes, we add a check for the DualReplica topology after the control-plane nodes
are provisioned during bootstrapping and detach them from ironic.
In a future release, when fencing is enabled, it will be important to enforce that this remains an invariant
for the DualReplica control-plane topology. There is currently nothing preventing the annotation that detaches
these nodes from being removed.
* pkg/types/azure: remove SystemAssigned ID
SystemAssigned Identities are not supported in any capacity in MAPZ.
Due to that they were feature gated for future CAPZ->MAPZ transition.
The CAPZ Identity API creates further issues in that, the value to be
used for name/scope is unclear and when deleting clusters the
role assignment of the identity is leaked.
No users have asked for this functionality, so lets revert it to
reduce our complexity and load.
* fixup! pkg/types/azure: remove SystemAssigned ID
If a CA cert is required to talk to your OpenStack then obviously all
services that talk to the cloud need to have both credentials and said
cert. Currently, these users can get their credentials via cloud
credential operator, but they need to source their CA cert from
elsewhere (typically by extracting it from the cloud controller
manager's configuration). This makes configuration of services more
complicated than necessary.
Continue the resolution of the issue by storing the CA cert, if any,
in the root secret on OpenStack. When coupled with the changes
introduced in openshift/cloud-credential-operator#780 [1], this allows
us to dole out the cert to anyone who asks for it via a
'CredentialsRequest'.
[1] https://github.com/openshift/cloud-credential-operator/pull/780
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Omitting the main pacemaker log in this initial implementation after discussion with pacemaker SME.
The `/var/log/pacemaker/pacemaker.log` has been shown to have the potential to contain sensitive
information. Since log collection happens regularly in CI, we will avoid collecting this log for the
time being. That said, I've left a comment explain how to pull it using `sos report` and have
also showed how to pull the log successfully (since it needs a permissions tweak) in the case that
these concerns are resolved at a later time.
This upstream issue can be used to follow progress on addressing security concerns in the pacemaker log.
https://projects.clusterlabs.org/T615
