Update URLs to latest versions

enhancements/machine-config/machine-config-irreconcilable-changes.md

@@ -36,7 +36,7 @@ fields), locking the user into an Ignition specification for the rest of the
 life of the cluster.
 
 The exhaustive list of fields the MCD supports to be changed after the cluster 
-is built can be found in the ["What can you change with machine configs?"](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/machine_configuration/machine-config-index#what-can-you-change-with-machine-configs) 
+is built can be found in the ["What can you change with machine configs?"](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/machine_configuration/machine-config-index#what-can-you-change-with-machine-configs) 
 section of the official documentation.
 
 While this is generally useful for safety, it becomes problematic for any 

enhancements/machine-config/manage-boot-images.md

@@ -52,7 +52,7 @@ Additionally, the stub Ignition config [referenced](https://github.com/openshift
 
 The content served by the MCS includes the actual Ignition configuration and the target OCI format RHCOS image. The ignition binary now does first boot provisioning based on this, then hands off to the `machine-config-daemon`(MCD) first boot service to do the reboot into the target OCI format RHCOS image. 
 
-Hence, it is critical that the Ignition binary in the boot image is able to process the stub Ignition config to make the initial MCS request and join the cluster. On clusters installed [prior to 4.6](https://docs.redhat.com/en/documentation/openshift_container_platform/4.6/html/release_notes/ocp-4-6-release-notes#ocp-4-6-ignition-spect-updated-v3), the stub Ignition would be of the spec 2 format - which cannot be used by the newer boot images. In very rare cases, some users also [customize](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/postinstallation_configuration/post-install-node-tasks#machine-node-custom-partition_post-install-node-tasks) the original stub Ignition config. Therefore, to make boot image updates as seamless as possible, there is a need to upgrade these stub Ignition configs to the spec 3 format, while preserving any customizations done to it at install time.
+Hence, it is critical that the Ignition binary in the boot image is able to process the stub Ignition config to make the initial MCS request and join the cluster. On clusters installed [prior to 4.6](https://docs.redhat.com/en/documentation/openshift_container_platform/4.6/html/release_notes/ocp-4-6-release-notes#ocp-4-6-ignition-spect-updated-v3), the stub Ignition would be of the spec 2 format - which cannot be used by the newer boot images. In very rare cases, some users also [customize](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/postinstallation_configuration/post-install-node-tasks#machine-node-custom-partition_post-install-node-tasks) the original stub Ignition config. Therefore, to make boot image updates as seamless as possible, there is a need to upgrade these stub Ignition configs to the spec 3 format, while preserving any customizations done to it at install time.
 
 > **_NOTE:_** There has been [a previous effort](https://github.com/openshift/machine-config-operator/pull/1792) to manage the stub Ignition config. It was [reverted](https://github.com/openshift/machine-config-operator/pull/2126) and then [brought back](https://github.com/openshift/machine-config-operator/pull/2827#issuecomment-996156872) just for bare metal clusters. For other platforms, the `*-managed` stubs still get generated by the MCO, but are not injected into the `MachineSet`. Since they are generated and synced by the MCO, it ignores any user customizations. This proposal originally used the `*-managed` stubs in its initial implementation, but with the [MCS CA & TLS management](https://issues.redhat.com/browse/MCO-1208) work in place, the upgrade path mentioned above is preferred.
 
@@ -140,8 +140,8 @@ This is a tentative timeline for managed platforms, subject to change:
 
 | Platform | TechPreview (opt-in) | GA (opt-in) | Default-On (opt-out) |
 | -------- | ------- | ------- | ------- |
-| gcp      | [4.16](https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html-single/machine_configuration/index#mco-update-boot-images)    |[4.17](https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/machine_configuration/index#mco-update-boot-images)     |4.19     |
-| aws      | [4.17](https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html-single/machine_configuration/index#mco-update-boot-images)    |[4.18](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html-single/machine_configuration/index#mco-update-boot-images)     |4.19     |
+| gcp      | [4.16](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html-single/machine_configuration/index#mco-update-boot-images)    |[4.17](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html-single/machine_configuration/index#mco-update-boot-images)     |4.19     |
+| aws      | [4.17](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html-single/machine_configuration/index#mco-update-boot-images)    |[4.18](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html-single/machine_configuration/index#mco-update-boot-images)     |4.19     |
 | vsphere  | 4.20    |4.21     |4.22     |
 | azure    | 4.20    |4.21     |4.22     |
 | openstack| 4.21        |4.22     |4.23     |
@@ -747,7 +747,7 @@ A potential problem here is that the way boot images are stored in the machinese
 
 #### Reactive
 1. Have the MCS reject new ignition requests if the aformentioned object indicates that the cluster's bootimages are out of date. The MCS would then signal to the cluster admin that scale-up is not available until the skew has been resolved. Raising the alarm from the MCS at the cluster level will help prevent additional noise for the cluster infra team, and make apparent that the scaling failure was intentional. The MCS will also attempt to serve an Ignition config that writes a message to `/etc/issue` explaining that the bootimage is too old, which will be visible from the node's console.
-2. Add a service to be shipped via RHCOS/MCO templates, which will do a check on incoming OS container image vs currently booted RHCOS version. This runs on firstboot right after the MCD pulls the new image, and will prevent the node to rebase to the updated image if the drift is too far. This would cover environments that do not use the MCS such as [installing via ISO on bare metal](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/installing_on_bare_metal/user-provisioned-infrastructure#installation-user-infra-machines-iso_installing-bare-metal).
+2. Add a service to be shipped via RHCOS/MCO templates, which will do a check on incoming OS container image vs currently booted RHCOS version. This runs on firstboot right after the MCD pulls the new image, and will prevent the node to rebase to the updated image if the drift is too far. This would cover environments that do not use the MCS such as [installing via ISO on bare metal](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/installing_on_bare_metal/user-provisioned-infrastructure#installation-user-infra-machines-iso_installing-bare-metal).
 
 RHEL major versions will no longer be cross-compatible. i.e. if you wish to have a RHEL10 machineconfigpool, you must use a RHEL10 bootimage.