Skip to content

OSDOCS-14876#RN Azure #94390

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 10, 2025
Merged

OSDOCS-14876#RN Azure #94390

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 15 additions & 7 deletions release_notes/ocp-4-19-release-notes.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -475,6 +475,7 @@ In {product-title} {product-version}, the installation program uses the Cluster

[id="ocp-4-19-installation-and-update-azure-outbound-access-vms_{context}"]
==== Outbound access for VMs in {azure-first} will be retired

On 30 September 2025, the default outbound access connectivity for all new virtual machines (VMs) in {azure-first} will be retired. To enhance security, {azure-short} is moving towards a secure-by-default model where default outbound access to the internet will be turned off. However, configuration changes to {product-title} are not required. By default, the installation program creates an outbound rule for the load balancer.

For more information, see link:https://azure.microsoft.com/en-us/updates?id=default-outbound-access-for-vms-in-azure-will-be-retired-updates-and-more-information[Azure Updates] (Microsoft documentation), link:https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections#scenarios[Azure's outbound connectivity methods] (Microsoft documentation), and xref:../installing/installing_azure/upi/installing-azure-preparing-upi.adoc#installing-azure-preparing-upi[Preparing to install a cluster on {azure-short}].
Expand Down Expand Up @@ -502,6 +503,13 @@ With this release, you can install a cluster on {vmw-first} with multiple storag

For more information, see xref:../installing/installing_vsphere/installation-config-parameters-vsphere.html#installation-configuration-parameters-optional-vsphere_installation-config-parameters-vsphere[Optional vSphere configuration parameters].

[id="ocp-4-19-installation-and-update-azure-boot-diagnostics_{context}"]
==== Enabling boot diagnostics collection during installation on {azure-first}

With this release, you can enable boot diagnostics collection when you install a cluster on {azure-first}. Boot diagnostics is a debugging feature for {azure-short} virtual machines (VMs) to identify VM boot failures. You can set the `bootDiagnostics` parameter in the `install-config.yaml` file for compute machines, for control plane machines, or for all machines.

For more information, see xref:../installing/installing_azure/installation-config-parameters-azure.adoc#installation-configuration-parameters-additional-azure_installation-config-parameters-azure[Additional {azure-short} configuration parameters].

[id="ocp-4-19-admin-ack-updating_{context}"]
==== Required administrator acknowledgment when updating from {product-title} 4.18 to 4.19

Expand Down Expand Up @@ -540,11 +548,11 @@ Image mode for OpenShift, formerly called on-cluster layering, is now Generally

* The `global-pull-secret-copy` is automatically added to the `openshift-machine-config-operator` namespace.

* You can now revert an on-cluster custom layered image back to the base image by removing a label from the `MachineOSConfig` object
* You can now revert an on-cluster custom layered image back to the base image by removing a label from the `MachineOSConfig` object

* You can now automatically delete an on-cluster custom layered image by deleting the associated `MachineOSBuild` object.
* You can now automatically delete an on-cluster custom layered image by deleting the associated `MachineOSBuild` object.

* The `must-gather` for the Machine Config Operator now includes data on the `MachineOSConfig` and `MachineOSBuild` objects.
* The `must-gather` for the Machine Config Operator now includes data on the `MachineOSConfig` and `MachineOSBuild` objects.

* On-cluster layering is now supported in disconnected environments.

Expand All @@ -553,9 +561,9 @@ Image mode for OpenShift, formerly called on-cluster layering, is now Generally
[id="ocp-release-notes-machine-config-operator-boot-image_{context}"]
==== Boot image management is now default for {gcp-first} and {aws-first}

The boot image management feature, previously called updated boot images, is now the default behavior in {gcp-first} and {aws-first} clusters. As such, after updating to {product-title} {product-version}, the boot images in your cluster are automatically updated to version {product-version}. With subsequent updates, the Machine Config Operator (MCO) again updates the boot images in your cluster. A boot images is associated with a machine set and is used when scaling new nodes. Any new nodes you create after updating are based on the new version. Current nodes are not affected by this feature.
The boot image management feature, previously called updated boot images, is now the default behavior in {gcp-first} and {aws-first} clusters. As such, after updating to {product-title} {product-version}, the boot images in your cluster are automatically updated to version {product-version}. With subsequent updates, the Machine Config Operator (MCO) again updates the boot images in your cluster. A boot images is associated with a machine set and is used when scaling new nodes. Any new nodes you create after updating are based on the new version. Current nodes are not affected by this feature.

Before upgrading to {product-version}, you must opt-out of this default behavior or acknowledge this change before proceeding. For more information, see xref:../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images-disable_machine-configs-configure[Disabling boot image management].
Before upgrading to {product-version}, you must opt-out of this default behavior or acknowledge this change before proceeding. For more information, see xref:../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images-disable_machine-configs-configure[Disabling boot image management].

[NOTE]
====
Expand All @@ -569,7 +577,7 @@ The MCS signing key is stored in the `machine-config-server-ca` secret in the `o

The MCS CA and MCS cert are valid for 10 years and are automatically rotated by the MCO at approximately 8 years. Upon update to {product-title} {product-version}, the CA signing key is not present. As a result, the CA bundle is immediately considered expired when the MCO certificate controller comes up. This expiration causes an immediate certificate rotation, even if the cluster is not 10 years old. After that point, the next rotation takes place at the standard 8 year period.

For more information about the MCO certificates, see xref:../security/certificate_types_descriptions/machine-config-operator-certificates.adoc#cert-types-machine-config-operator-certificates[Machine Config Operator certificates].
For more information about the MCO certificates, see xref:../security/certificate_types_descriptions/machine-config-operator-certificates.adoc#cert-types-machine-config-operator-certificates[Machine Config Operator certificates].

[id="ocp-release-notes-management-console_{context}"]
=== Management console
Expand Down Expand Up @@ -677,7 +685,7 @@ For more information, see xref:../networking/ptp/ptp-cloud-events-consumer-dev-r
[id="ocp-release-notes-machine-config-operator-cgroup-v1_{context}"]
==== cgroup v1 has been removed

cgroup v1, which was deprecated in {product-title} 4.16, is no longer supported and has been removed from {product-title}. If your cluster is using cgroup v1, you must configure cgroup v2 before you can upgrade to {product-title} {product-version}. All workloads must now be compatible with cgroup v2.
cgroup v1, which was deprecated in {product-title} 4.16, is no longer supported and has been removed from {product-title}. If your cluster is using cgroup v1, you must configure cgroup v2 before you can upgrade to {product-title} {product-version}. All workloads must now be compatible with cgroup v2.

For more information on cgroup v2, see xref:../architecture/index.adoc#architecture-about-cgroup-v2_architecture-overview[About Linux cgroup version 2] and link:https://www.redhat.com/en/blog/rhel-9-changes-context-red-hat-openshift-workloads[Red Hat Enterprise Linux 9 changes in the context of Red Hat OpenShift workloads] (Red{nbsp}Hat blog).

Expand Down