MCO 4.19 Release Notes

release_notes/ocp-4-19-release-notes.adoc

@@ -427,6 +427,48 @@ Starting in {product-title} 4.14, Extended Update Support (EUS) is extended to t
 [id="ocp-release-notes-machine-config-operator_{context}"]
 === Machine Config Operator
 
+[id="ocp-release-notes-machine-config-operator-ocl-ga_{context}"]
+==== On-cluster layering is now generally available
+
+With the promotion to General Availability, there are several important changes to the on-cluster layering feature:
+
+* The API version is now `machineconfiguration.openshift.io/v1`. The new version includes the following changes:
+** The `baseImagePullSecret` parameter is now optional. If not specified, the default `global-pull-secret-copy` is used.
+** The `buildInputs` parameter is no longer required. All parameters previously under the `buildInputs` parameter are promoted one level.
+** The `containerfileArch` parameter now supports multiple architectures. Previously, only `noarch` was supported.
+** The required `imageBuilderType` is now `Job`. Previously, the required builder was `PodImageBuilder`.
+** The `renderedImagePushspec` parameter is now `renderedImagePushSpec`.
+** The `buildOutputs` and `currentImagePullSecret` parameters are no longer required.
+
+* The output of the `oc describe MachineOSConfig` and `oc describe MachineOSBuild` commands have multiple differences.
+
+* The `global-pull-secret` 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 automatically delete a 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. 
+
+* On-cluster layering is now supported in disconnected environments.
+
+* On-cluster layering is now supported in single node OpenShift (SNO) clusters.
+
+[id="ocp-release-notes-machine-config-operator-cert-changes_{context}"]
+==== Updated boot image now default on GCP and AWS clusters
+
+The updated boot images feature, which updates the boot image in your cluster when you update the cluster, is now active by default on GCP and AWS clusters. Without updating the boot image, the boot image that the cluster uses to create nodes is the same as when the cluster was created. For GCP and AWS clusters, you can opt-out of the feature, as necessary. For more information, see xref:../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images[Updated boot images].
+
+[id="ocp-release-notes-machine-config-operator-cert-changes_{context}"]
+==== Changes to the Machine Config Operator certificates
+The Machine Config Server (MCS) CA bundle created by the installation program is now stored in the `machine-config-server-ca` config map in the `openshift-machine-config-operator` namespace. The bundle was previously stored in the `root-ca` configmap in the `kube-system namespace`. The `root-ca` configmap is no longer used in a cluster that cluster upgrades to {product-title} {product-version}. This change was made to make it clear that this CA bundle is managed by the Machine Config Operator (MCO).
+
+The MCS signing key is stored in the `machine-config-server-ca` secret in the `openshift-machine-config-operator` namespace.
+
+The MCS CA and MCS cert are valid for 10 years and are automatically rotated by the MCO at approximately 8 years. Upon upgrade 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 ../security_and_compliance/certificate-types-and-descriptions.adoc#cert-types-machine-config-operator-certificates
+
 [id="ocp-release-notes-management-console_{context}"]
 === Management console
 
@@ -462,6 +504,15 @@ For more information, see xref:../networking/ptp/about-ptp.adoc#ptp-dual-ports-o
 [id="ocp-release-notes-nodes_{context}"]
 === Nodes
 
+[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. 
+
+For information on configuring cgroup v2, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/nodes/working-with-clusters#nodes-clusters-cgroups-2_nodes-cluster-cgroups-2[Configuring Linux cgroup] in the {product-title} 4.18 documentation.
+
+For more information on cgroup v2, see _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].
+
 [id="ocp-release-notes-postinstallation-configuration_{context}"]
 === Postinstallation configuration
 
@@ -1104,16 +1155,11 @@ In the following tables, features are marked with the following statuses:
 |On-cluster RHCOS image layering
 |Technology Preview
 |Technology Preview
-|Technology Preview
-
-|Node disruption policies
-|General Availability
-|General Availability
 |General Availability
 
-|Updating boot images for GCP clusters
-|General Availability
-|General Availability
+|Machine Config Nodes
+|Technology Preview
+|Technology Preview
 |General Availability
 
 |Updating boot images for AWS clusters