openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

Fix Bump MCO build errors

Browse Source
This commit is contained in:
Michael Burke
2023-06-20 09:27:42 -04:00
parent 8cee429729
commit fd82c7fac5
64 changed files with 458 additions and 138 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
_topic_maps/_topic_map.yml
View File

@@ -605,8 +605,6 @@ Topics:
File: vsphere-post-installation-encryption
- Name: Configuring the vSphere connection settings after an installation
File: installing-vsphere-post-installation-configuration
- Name: Machine configuration tasks
File: machine-configuration-tasks
- Name: Cluster tasks
File: cluster-tasks
- Name: Node tasks
@@ -630,12 +628,6 @@ Topics:
File: ibmz-post-install
- Name: Regions and zones for a VMware vCenter
File: post-install-vsphere-zones-regions-configuration
- Name: Red Hat Enterprise Linux CoreOS image layering
File: coreos-layering
Distros: openshift-enterprise
- Name: Fedora CoreOS image layering
File: coreos-layering
Distros: openshift-origin
- Name: Adding failure domains to an existing Nutanix cluster
File: adding-nutanix-failure-domains
Distros: openshift-origin,openshift-enterprise
@@ -2231,6 +2223,31 @@ Topics:
- Name: Serverless overview
File: about-serverless
---
Name: Machine configuration
Dir: machine_configuration
Distros: openshift-enterprise, openshift-origin
Topics:
- Name: Machine configuration overview
File: index
- Name: Using machine config objects to configure nodes
File: machine-configs-configure
- Name: Understanding node restart behaviors after machine config changes
File: machine-config-node-disruption
- Name: Configuring MCO-related custom resources
File: machine-configs-custom
- Name: Updated boot images
File: mco-update-boot-images
- Name: Managing unused rendered machine configs
File: machine-configs-garbage-collection
- Name: Red Hat Enterprise Linux (RHEL) CoreOS image layering
File: mco-coreos-layering
Distros: openshift-enterprise
- Name: Fedora CoreOS image layering
File: mco-coreos-layering
Distros: openshift-origin
- Name: Machine Config Daemon metrics
File: machine-config-daemon-metrics
---
Name: Machine management
Dir: machine_management
Distros: openshift-origin,openshift-enterprise
@@ -2553,8 +2570,6 @@ Topics:
Distros: openshift-enterprise,openshift-origin
# - Name: Monitoring for problems in your nodes
# File: nodes-nodes-problem-detector
- Name: Machine Config Daemon metrics
File: nodes-nodes-machine-config-daemon-metrics
- Name: Creating infrastructure nodes
File: nodes-nodes-creating-infrastructure-nodes
- Name: Working with containers

2
_topic_maps/_topic_map_osd.yml
View File

@@ -1115,8 +1115,6 @@ Topics:
# Distros: openshift-dedicated
# - Name: Monitoring for problems in your nodes
# File: nodes-nodes-problem-detector
- Name: Machine Config Daemon metrics
File: nodes-nodes-machine-config-daemon-metrics
# cannot patch resource "nodes"
# - Name: Creating infrastructure nodes
# File: nodes-nodes-creating-infrastructure-nodes

2
_topic_maps/_topic_map_rosa.yml
View File

@@ -1381,8 +1381,6 @@ Topics:
# Distros: openshift-rosa
# - Name: Monitoring for problems in your nodes
# File: nodes-nodes-problem-detector
# - Name: Machine Config Daemon metrics
# File: nodes-nodes-machine-config-daemon-metrics
# cannot patch resource "nodes"
# - Name: Creating infrastructure nodes
# File: nodes-nodes-creating-infrastructure-nodes

6
architecture/control-plane.adoc
View File

@@ -28,7 +28,7 @@ endif::openshift-dedicated,openshift-rosa[]
ifndef::openshift-dedicated,openshift-rosa[]
[role="_additional-resources"]
.Additional resources
* xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-drift-detection_post-install-machine-configuration-tasks[Understanding configuration drift detection]
* xref:../machine_configuration/index.adoc#machine-config-drift-detection_machine-config-overview[Understanding configuration drift detection]
endif::openshift-dedicated,openshift-rosa[]
include::modules/architecture-machine-roles.adoc[leveloffset=+1]
@@ -59,11 +59,11 @@ endif::openshift-dedicated,openshift-rosa[]
ifndef::openshift-dedicated,openshift-rosa[]
[role="_additional-resources"]
.Additional resources
* For more information about detecting configuration drift, see xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-drift-detection_post-install-machine-configuration-tasks[Understanding configuration drift detection].
* For more information about detecting configuration drift, see xref:../machine_configuration/index.adoc#machine-config-drift-detection_machine-config-overview[Understanding configuration drift detection].
* For information about preventing the control plane machines from rebooting after the Machine Config Operator makes changes to the machine configuration, see xref:../support/troubleshooting/troubleshooting-operator-issues.adoc#troubleshooting-disabling-autoreboot-mco_troubleshooting-operator-issues[Disabling Machine Config Operator from automatically rebooting].
* xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-node-disruption_post-install-machine-configuration-tasks[Understanding node restart behaviors after machine config changes]
* xref:../machine_configuration/machine-config-node-disruption.adoc#machine-config-node-disruption[Understanding node restart behaviors after machine config changes]
endif::openshift-dedicated,openshift-rosa[]
include::modules/etcd-overview.adoc[leveloffset=+1]

4
hardware_enablement/kmm-kernel-module-management.adoc
View File

@@ -134,7 +134,7 @@ include::modules/kmm-customizing-upgrades-for-kernel-modules.adoc[leveloffset=+1
include::modules/kmm-day1-kernel-module-loading.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-operator_post-install-machine-configuration-tasks[Machine Config Operator]
* xref:../machine_configuration/index.adoc#machine-config-index[Machine Config Operator]
include::modules/kmm-day1-supported-use-cases.adoc[leveloffset=+2]
include::modules/kmm-day1-oot-kernel-module-loading-flow.adoc[leveloffset=+2]
@@ -160,7 +160,7 @@ include::modules/kmm-firmware-support.adoc[leveloffset=+1]
include::modules/kmm-configuring-the-lookup-path-on-nodes.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* xref:../post_installation_configuration/machine-configuration-tasks.adoc#understanding-the-machine-config-operator[Machine Config Operator]
* xref:../machine_configuration/index.adoc#machine-config-operator_machine-config-overview[Machine Config Operator].
include::modules/kmm-building-a-kmod-image.adoc[leveloffset=+2]
include::modules/kmm-tuning-the-module-resource.adoc[leveloffset=+2]

2
installing/installing_ibm_power/installing-ibm-power.adoc
View File

@@ -127,7 +127,7 @@ include::modules/cluster-telemetry.adoc[leveloffset=+1]
== Next steps
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#rhcos-enabling-multipath_post-install-machine-configuration-tasks[Enabling multipathing with kernel arguments on {op-system}].
* xref:../../machine_configuration/machine-configs-configure.adoc#rhcos-enabling-multipath-day-2_machine-configs-configure[Enabling multipathing with kernel arguments on {op-system}].
* xref:../../post_installation_configuration/cluster-tasks.adoc#available_cluster_customizations[Customize your cluster].
* If necessary, you can
xref:../../support/remote_health_monitoring/opting-out-of-remote-health-reporting.adoc#opting-out-remote-health-reporting_opting-out-remote-health-reporting[opt out of remote health reporting].

2
installing/installing_ibm_power/installing-restricted-networks-ibm-power.adoc
View File

@@ -132,7 +132,7 @@ include::modules/installation-complete-user-infra.adoc[leveloffset=+1]
== Next steps
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#rhcos-enabling-multipath_post-install-machine-configuration-tasks[Enabling multipathing with kernel arguments on {op-system}].
* xref:../../machine_configuration/machine-configs-configure.adoc#rhcos-enabling-multipath-day-2_machine-configs-configure[Enabling multipathing with kernel arguments on {op-system}].
* xref:../../post_installation_configuration/cluster-tasks.adoc#available_cluster_customizations[Customize your cluster].
* If the mirror registry that you used to install your cluster has a trusted CA, add it to the cluster by xref:../../openshift_images/image-configuration.adoc#images-configuration-cas_image-configuration[configuring additional trust stores].
* If necessary, you can xref:../../support/remote_health_monitoring/opting-out-of-remote-health-reporting.adoc#opting-out-remote-health-reporting_opting-out-remote-health-reporting[opt out of remote health reporting].

2
installing/installing_ibm_z/installing-ibm-z-lpar.adoc
View File

@@ -141,7 +141,7 @@ include::modules/cluster-telemetry.adoc[leveloffset=+1]
[id="next-steps_installing-ibm-z-lpar"]
== Next steps
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#rhcos-enabling-multipath_post-install-machine-configuration-tasks[Enabling multipathing with kernel arguments on {op-system}].
* xref:../../machine_configuration/machine-configs-configure.adoc#rhcos-enabling-multipath-day-2_machine-configs-configure[Enabling multipathing with kernel arguments on {op-system}].
* xref:../../post_installation_configuration/cluster-tasks.adoc#available_cluster_customizations[Customize your cluster].

2
installing/installing_ibm_z/installing-ibm-z.adoc
View File

@@ -147,7 +147,7 @@ include::modules/cluster-telemetry.adoc[leveloffset=+1]
[id="next-steps_ibmz-vm"]
== Next steps
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#rhcos-enabling-multipath_post-install-machine-configuration-tasks[Enabling multipathing with kernel arguments on {op-system}].
* xref:../../machine_configuration/machine-configs-configure.adoc#rhcos-enabling-multipath-day-2_machine-configs-configure[Enabling multipathing with kernel arguments on {op-system}].
* xref:../../post_installation_configuration/cluster-tasks.adoc#available_cluster_customizations[Customize your cluster].

2
installing/installing_with_agent_based_installer/installing-with-agent-based-installer.adoc
View File

@@ -46,7 +46,7 @@ include::modules/installing-ocp-agent-manifest-folder.adoc[leveloffset=+3]
[role="_additional-resources"]
.Additional resources
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#using-machineconfigs-to-change-machines[Using MachineConfig objects to configure nodes]
* xref:../../machine_configuration/machine-configs-configure.adoc#machine-configs-configure[Using MachineConfig objects to configure nodes]
// Partitioning the disk
include::modules/installation-user-infra-machines-advanced.adoc[leveloffset=+3]

1
machine_configuration/_attributes Symbolic link
View File

@@ -0,0 +1 @@
../_attributes/

1
machine_configuration/images Symbolic link
View File

@@ -0,0 +1 @@
../images

42
machine_configuration/index.adoc Normal file
View File

@@ -0,0 +1,42 @@
:_mod-docs-content-type: ASSEMBLY
:context: machine-config-overview
[id="machine-config-index"]
= Machine configuration overview
include::_attributes/common-attributes.adoc[]
toc::[]
There are times when you need to make changes to the operating systems running on {product-title} nodes. This can include changing settings for network time service, adding kernel arguments, or configuring journaling in a specific way.
Aside from a few specialized features, most changes to operating systems on {product-title} nodes can be done by creating what are referred to as `MachineConfig` objects that are managed by the Machine Config Operator. For example, you can use the Machine Config Operator (MCO) and machine configs to manage update to systemd, CRI-O and kubelet, the kernel, Network Manager and other system features.
Tasks in this section describe how to use features of the Machine Config Operator to configure operating system features on {product-title} nodes.
[IMPORTANT]
====
NetworkManager stores new network configurations to `/etc/NetworkManager/system-connections/` in a key file format.
Previously, NetworkManager stored new network configurations to `/etc/sysconfig/network-scripts/` in the `ifcfg` format. Starting with RHEL 9.0, RHEL stores new network configurations at `/etc/NetworkManager/system-connections/` in a key file format. The connections configurations stored to `/etc/sysconfig/network-scripts/` in the old format still work uninterrupted. Modifications in existing profiles continue updating the older files.
====
include::modules/understanding-machine-config-operator.adoc[leveloffset=+1]
.Additional resources
* xref:../networking/openshift_sdn/about-openshift-sdn.adoc#about-openshift-sdn[About the OpenShift SDN network plugin]
include::modules/machine-config-overview.adoc[leveloffset=+1]
include::modules/machine-config-drift-detection.adoc[leveloffset=+1]
include::modules/checking-mco-status.adoc[leveloffset=+1]
include::modules/checking-mco-node-status.adoc[leveloffset=+1]
[id="machine-config-operator-certificates_{context}"]
== Understanding Machine Config Operator certificates
Machine Config Operator certificates are used to secure connections between the Red Hat Enterprise Linux CoreOS (RHCOS) nodes and the Machine Config Server. For more information, see xref:../security/certificate_types_descriptions/machine-config-operator-certificates.adoc#cert-types-machine-config-operator-certificates[Machine Config Operator certificates].
include::modules/checking-mco-status-certs.adoc[leveloffset=+2]

13
nodes/nodes/nodes-nodes-machine-config-daemon-metrics.adoc → machine_configuration/machine-config-daemon-metrics.adoc
View File

@@ -1,20 +1,21 @@
:_mod-docs-content-type: ASSEMBLY
[id="machine-config-daemon-metrics"]
= Machine Config Daemon metrics
= Machine Config Daemon metrics overview
include::_attributes/common-attributes.adoc[]
:context: machine-config-operator
toc::[]
The Machine Config Daemon is a part of the Machine Config Operator. It runs on every node in the cluster. The Machine Config Daemon manages configuration changes and updates on each of the nodes.
include::modules/machine-config-daemon-metrics.adoc[leveloffset=+1]
include::modules/machine-config-daemon-metrics-understanding.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
ifndef::openshift-rosa,openshift-dedicated[]
* xref:../../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
* xref:../../support/gathering-cluster-data.adoc#gathering-cluster-data[Gathering data about your cluster]
* xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview]
* xref:../support/gathering-cluster-data.adoc#gathering-cluster-data[Gathering data about your cluster]
endif::openshift-rosa,openshift-dedicated[]
ifdef::openshift-rosa,openshift-dedicated[]
* xref:../../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Understanding the monitoring stack]
* xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Understanding the monitoring stack]
endif::openshift-rosa,openshift-dedicated[]

41
machine_configuration/machine-config-node-disruption.adoc Normal file
View File

@@ -0,0 +1,41 @@
:_mod-docs-content-type: ASSEMBLY
:context: machine-configs-configure
[id="machine-config-node-disruption_{context}"]
= Using node disruption policies to minimize disruption from machine config changes
include::_attributes/common-attributes.adoc[]
toc::[]
By default, when you make certain changes to the fields in a `MachineConfig` object, the Machine Config Operator (MCO) drains and reboots the nodes associated with that machine config. However, you can create a _node disruption policy_ that defines a set of changes to some Ignition config objects that would require little or no disruption to your workloads.
A node disruption policy allows you to define the configuration changes that cause a disruption to your cluster, and which changes do not. This allows you to reduce node downtime when making small machine configuration changes in your cluster. To configure the policy, you modify the `MachineConfiguration` object, which is in the `openshift-machine-config-operator` namespace. See the example node disruption policies in the `MachineConfiguration` objects that follow.
[NOTE]
====
There are machine configuration changes that always require a reboot, regardless of any node disruption policies. For more information, see _About the Machine Config Operator_.
====
After you create the node disruption policy, the MCO validates the policy to search for potential issues in the file, such as problems with formatting. The MCO then merges the policy with the cluster defaults and populates the `status.nodeDisruptionPolicyStatus` fields in the machine config with the actions to be performed upon future changes to the machine config. The configurations in your policy always overwrite the cluster defaults.
[IMPORTANT]
====
The MCO does not validate whether a change can be successfully applied by your node disruption policy. Therefore, you are responsible to ensure the accuracy of your node disruption policies.
====
For example, you can configure a node disruption policy so that sudo configurations do not require a node drain and reboot. Or, you can configure your cluster so that updates to `sshd` are applied with only a reload of that one service.
:FeatureName: The node disruption policy feature
include::snippets/technology-preview.adoc[]
You can control the behavior of the MCO when making the changes to the following Ignition configuration objects:
// I used this wording for the objects to match the previous section in the assembly: file:///home/mburke/openshift-docs/_preview/openshift-enterprise/mco-node-disruption-policy/post_installation_configuration/machine-configuration-tasks.html#what-can-you-change-with-machine-configs.
* *configuration files*: You add to or update the files in the `/var` or `/etc` directory.
* *systemd units*: You create and set the status of a systemd service or modify an existing systemd service.
* *users and groups*: You change SSH keys in the `passwd` section postinstallation.
* *ICSP*, *ITMS*, *IDMS* objects: You can remove mirroring rules from an `ImageContentSourcePolicy` (ICSP), `ImageTagMirrorSet` (ITMS), and `ImageDigestMirrorSet` (IDMS) object.
include::snippets/machine-config-node-disruption-actions.adoc[]
include::modules/machine-config-node-disruption-example.adoc[leveloffset=+1]
include::modules/machine-config-node-disruption-config.adoc[leveloffset=+1]

53
machine_configuration/machine-configs-configure.adoc Normal file
View File

@@ -0,0 +1,53 @@
:_mod-docs-content-type: ASSEMBLY
:context: machine-configs-configure
[id="machine-configs-configure"]
= Using machine config objects to configure nodes
include::_attributes/common-attributes.adoc[]
toc::[]
You can use the tasks in this section to create `MachineConfig` objects that modify files, systemd unit files, and other operating system features running on {product-title} nodes. For more ideas on working with machine configs, see content related to link:https://access.redhat.com/solutions/3868301[updating] SSH authorized keys, link:https://access.redhat.com/verify-images-ocp4[verifying image signatures], link:https://access.redhat.com/solutions/4727321[enabling SCTP], and link:https://access.redhat.com/solutions/5170251[configuring iSCSI initiatornames] for {product-title}.
{product-title} supports link:https://coreos.github.io/ignition/configuration-v3_2/[Ignition specification version 3.2]. All new machine configs you create going forward should be based on Ignition specification version 3.2. If you are upgrading your {product-title} cluster, any existing Ignition specification version 2.x machine configs will be translated automatically to specification version 3.2.
There might be situations where the configuration on a node does not fully match what the currently-applied machine config specifies. This state is called _configuration drift_. The Machine Config Daemon (MCD) regularly checks the nodes for configuration drift. If the MCD detects configuration drift, the MCO marks the node `degraded` until an administrator corrects the node configuration. A degraded node is online and operational, but, it cannot be updated. For more information on configuration drift, see xref:../machine_configuration/index.adoc#machine-config-drift-detection_machine-config-overview[Understanding configuration drift detection].
[TIP]
====
Use the following "Configuring chrony time service" procedure as a model for how to go about adding other configuration files to {product-title} nodes.
====
include::modules/installation-special-config-chrony.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../installing/install_config/installing-customizing.adoc#installation-special-config-butane_installing-customizing[Creating machine configs with Butane]
include::modules/cnf-disable-chronyd.adoc[leveloffset=+1]
include::modules/nodes-nodes-kernel-arguments.adoc[leveloffset=+1]
include::modules/rhcos-enabling-multipath-day-2.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* See xref:../installing/installing_bare_metal/installing-bare-metal.adoc#rhcos-enabling-multipath_installing-bare-metal[Enabling multipathing with kernel arguments on RHCOS] for more information about enabling multipathing during installation time.
include::modules/nodes-nodes-rtkernel-arguments.adoc[leveloffset=+1]
include::modules/machineconfig-modify-journald.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../installing/install_config/installing-customizing.adoc#installation-special-config-butane_installing-customizing[Creating machine configs with Butane]
include::modules/rhcos-add-extensions.adoc[leveloffset=+1]
include::modules/rhcos-load-firmware-blobs.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../installing/install_config/installing-customizing.adoc#installation-special-config-butane_installing-customizing[Creating machine configs with Butane]
include::modules/core-user-password.adoc[leveloffset=+1]

16
machine_configuration/machine-configs-custom.adoc Normal file
View File

@@ -0,0 +1,16 @@
:_mod-docs-content-type: ASSEMBLY
:context: machine-configs-custom
[id="machine-configs-custom"]
= Configuring MCO-related custom resources
include::_attributes/common-attributes.adoc[]
toc::[]
Besides managing `MachineConfig` objects, the MCO manages two custom resources (CRs): `KubeletConfig` and `ContainerRuntimeConfig`. Those CRs let you change node-level settings impacting how the kubelet and CRI-O container runtime services behave.
include::modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc[leveloffset=+1]
include::modules/create-a-containerruntimeconfig-crd.adoc[leveloffset=+1]
include::modules/set-the-default-max-container-root-partition-size-for-overlay-with-crio.adoc[leveloffset=+1]

24
machine_configuration/machine-configs-garbage-collection.adoc Normal file
View File

@@ -0,0 +1,24 @@
:_mod-docs-content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="machine-configs-garbage-collection"]
= Managing unused rendered machine configs
:context: machine-configs-garbage-collection
toc::[]
The Machine Config Operator (MCO) does not perform any garbage collection activities. This means that all rendered machine configs remain in the cluster. Each time a user or controller applies a new machine config, the MCO creates new rendered configs for each affected machine config pool. Over time, this can lead to a large number of rendered machine configs, which can make working with machine configs confusing. Having too many rendered machine configs can also contribute to disk space issues and performance issues with etcd.
You can remove old, unused rendered machine configs by using the `oc adm prune renderedmachineconfigs` command with the `--confirm` flag. With this command, you can remove all unused rendered machine configs or only those in a specific machine config pool. You can also remove a specified number of unused rendered machine configs in order to keep some older machine configs, in case you want to check older configurations.
You can use the `oc adm prune renderedmachineconfigs` command without the `--confirm` flag to see which rendered machine configs would be removed.
Use the `list` subcommand to display all the rendered machine configs in the cluster or a specific machine config pool.
[NOTE]
====
The `oc adm prune renderedmachineconfigs` command deletes only rendered machine configs that are not in use. If a rendered machine configs are in use by a machine config pool, the rendered machine config is not deleted. In this case, the command output specifies the reason that the rendered machine config was not deleted.
====
include::modules/machineconfig-garbage-collect-viewing.adoc[leveloffset=+1]
include::modules/machineconfig-garbage-collect-removing.adoc[leveloffset=+1]

16
post_installation_configuration/coreos-layering.adoc → machine_configuration/mco-coreos-layering.adoc
View File

@@ -1,8 +1,8 @@
:_mod-docs-content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="coreos-layering"]
[id="mco-coreos-layering"]
= {op-system} image layering
:context: coreos-layering
:context: mco-coreos-layering
toc::[]
@@ -14,7 +14,7 @@ toc::[]
Image layering allows you to customize the underlying node operating system on any of your cluster worker nodes. This helps keep everything up-to-date, including the node operating system and any added customizations such as specialized software.
You create a custom layered image by using a Containerfile and applying it to nodes by using a custom object. At any time, you can remove the custom layered image by deleting that custom object.
You create a custom layered image by using a Containerfile and applying it to nodes by using a custom object. At any time, you can remove the custom layered image by deleting that custom object.
With {op-system} image layering, you can install RPMs into your base image, and your custom content will be booted alongside {op-system}. The Machine Config Operator (MCO) can roll out these custom layered images and monitor these custom containers in the same way it does for the default {op-system} image. {op-system} image layering gives you greater flexibility in how you manage your {op-system} nodes.
@@ -29,16 +29,14 @@ As soon as you apply the custom layered image to your cluster, you effectively _
There are two methods for deploying a custom layered image onto your nodes:
On-cluster layering:: With xref:../post_installation_configuration/coreos-layering.adoc#coreos-layering-configuring-on_coreos-layering[on-cluster layering], you create a `MachineOSConfig` object where you include the Containerfile and other parameters. The build is performed on your cluster and the resulting custom layered image is automatically pushed to your repository and applied to the machine config pool that you specified in the `MachineOSConfig` object. The entire process is performed completely within your cluster.
On-cluster layering:: With xref:../machine_configuration/mco-coreos-layering.adoc#coreos-layering-configuring-on_mco-coreos-layering[on-cluster layering], you create a `MachineOSConfig` object where you include the Containerfile and other parameters. The build is performed on your cluster and the resulting custom layered image is automatically pushed to your repository and applied to the machine config pool that you specified in the `MachineOSConfig` object. The entire process is performed completely within your cluster.
+
--
:FeatureName: On-cluster image layering
include::snippets/technology-preview.adoc[]
--
Out-of-cluster layering:: With xref:../post_installation_configuration/coreos-layering.adoc#coreos-layering-configuring_coreos-layering[out-of-cluster layering], you create a Containerfile that references an {product-title} image and the RPM that you want to apply, build the layered image in your own environment, and push the image to your repository. Then, in your cluster, create a `MachineConfig` object for the targeted node pool that points to the new image. The Machine Config Operator overrides the base {op-system} image, as specified by the `osImageURL` value in the associated machine config, and boots the new image.
There is no functional difference between the custom layered images created by using either method. You can choose on- or off-cluster builds depending upon the needs of your organization.
Out-of-cluster layering:: With xref:../machine_configuration/mco-coreos-layering.adoc#coreos-layering-configuring_mco-coreos-layering[out-of-cluster layering], you create a Containerfile that references an {product-title} image and the RPM that you want to apply, build the layered image in your own environment, and push the image to your repository. Then, in your cluster, create a `MachineConfig` object for the targeted node pool that points to the new image. The Machine Config Operator overrides the base {op-system} image, as specified by the `osImageURL` value in the associated machine config, and boots the new image.
[IMPORTANT]
====
@@ -57,7 +55,7 @@ For both methods, use the same base {op-system} image installed on the rest of y
Some Hotfixes require a Red Hat Support Exception and are outside of the normal scope of {product-title} support coverage or life cycle policies.
====
+
In the event you want a Hotfix, it will be provided to you based on link:https://access.redhat.com/solutions/2996001[Red Hat Hotfix policy]. Apply it on top of the base image and test that new custom layered image in a non-production environment. When you are satisfied that the custom layered image is safe to use in production, you can roll it out on your own schedule to specific node pools. For any reason, you can easily roll back the custom layered image and return to using the default {op-system}.
Hotfixes are provided to you based on link:https://access.redhat.com/solutions/2996001[Red Hat Hotfix policy]. Apply it on top of the base image and test that new custom layered image in a non-production environment. When you are satisfied that the custom layered image is safe to use in production, you can roll it out on your own schedule to specific node pools. For any reason, you can easily roll back the custom layered image and return to using the default {op-system}.
+
.Example on-cluster Containerfile to apply a Hotfix
[source,yaml]
@@ -160,7 +158,7 @@ include::modules/coreos-layering-configuring-on.adoc[leveloffset=+1]
include::modules/coreos-layering-configuring.adoc[leveloffset=+1]
.Additional resources
xref:../post_installation_configuration/coreos-layering.adoc#coreos-layering-updating_coreos-layering[Updating with a {op-system} custom layered image]
xref:../machine_configuration/mco-coreos-layering.adoc#coreos-layering-updating_mco-coreos-layering[Updating with a {op-system} custom layered image]
include::modules/coreos-layering-removing.adoc[leveloffset=+1]
include::modules/coreos-layering-updating.adoc[leveloffset=+1]

61
machine_configuration/mco-update-boot-images.adoc Normal file
View File

@@ -0,0 +1,61 @@
:_mod-docs-content-type: ASSEMBLY
:context: machine-configs-configure
[id="mco-update-boot-images"]
= Updated boot images
include::_attributes/common-attributes.adoc[]
toc::[]
The Machine Config Operator (MCO) uses a boot image to start a {op-system-first} node. By default, {product-title} does not manage the boot image.
This means that the boot image in your cluster is not updated along with your cluster. For example, if your cluster was originally created with {product-title} 4.12, the boot image that the cluster uses to create nodes is the same 4.12 version, even if your cluster is at a later version. If the cluster is later upgraded to 4.13 or later, new nodes continue to scale with the same 4.12 image.
This process could cause the following issues:
* Extra time to start nodes
* Certificate expiration issues
* Version skew issues
To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters and is not supported for clusters managed by the Cluster API.
:FeatureName: The updating boot image feature
include::snippets/technology-preview.adoc[]
To view the current boot image used in your cluster, examine a machine set:
.Example machine set with the boot image reference
[source,yaml]
----
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
name: ci-ln-hmy310k-72292-5f87z-worker-a
namespace: openshift-machine-api
spec:
# ...
template:
# ...
spec:
# ...
providerSpec:
# ...
value:
disks:
- autoDelete: true
boot: true
image: projects/rhcos-cloud/global/images/rhcos-412-85-202203181601-0-gcp-x86-64 <1>
# ...
----
<1> This boot image is the same as the originally-installed {product-title} version, in this example {product-title} 4.12, regardless of the current version of the cluster. The way that the boot image is represented in the machine set depends on the platform, as the structure of the `providerSpec` field differs from platform to platform.
If you configure your cluster to update your boot images, the boot image referenced in your machine sets matches the current version of the cluster.
include::modules/mco-update-boot-images-configuring.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling[Enabling features using feature gates]
include::modules/mco-update-boot-images-disable.adoc[leveloffset=+1]

1
machine_configuration/modules Symbolic link
View File

@@ -0,0 +1 @@
../modules

1
machine_configuration/snippets Symbolic link
View File

@@ -0,0 +1 @@
../snippets

2
machine_management/creating_machinesets/creating-machineset-vsphere.adoc
View File

@@ -32,7 +32,7 @@ include::modules/machineset-upi-reqs-vsphere-creds.adoc[leveloffset=+2]
include::modules/machineset-upi-reqs-ignition-config.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#understanding-the-machine-config-operator[Understanding the Machine Config Operator]
* xref:../../machine_configuration/index.adoc#machine-config-operator_machine-config-overview[Understanding the Machine Config Operator]
* xref:../../installing/installing_vsphere/upi/installing-vsphere.adoc#installation-vsphere-machines_installing-vsphere[Installing {op-system} and starting the {product-title} bootstrap process]
//Creating a compute machine set

2
modules/checking-mco-status.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/index.adoc
:_mod-docs-content-type: PROCEDURE
[id="checking-mco-status_{context}"]

2
modules/core-user-password.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/machine-configs-configure.adoc
:_mod-docs-content-type: PROCEDURE
[id="core-user-password_{context}"]

6
modules/coreos-layering-configuring-on.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post-installation_configuration/coreos-layering.adoc
// * machine_configuration/coreos-layering.adoc
:_mod-docs-content-type: PROCEDURE
[id="coreos-layering-configuring-on_{context}"]
@@ -35,7 +35,7 @@ include::snippets/technology-preview.adoc[]
.Procedure
. Create a `MachineOSConfig` object:
. Create a `machineOSconfig` object:
.. Create a YAML file similar to the following:
+
@@ -82,7 +82,7 @@ $ oc create -f <file_name>.yaml
----
. If necessary, when the `MachineOSBuild` object has been created and is in the `READY` state, modify the node spec for the nodes where you want to use the new custom layered image:
+
.. Check that the `MachineOSBuild` object is `READY`. When the `SUCCEEDED` value is `True`, the build is complete.
+
[source,terminal]

2
modules/coreos-layering-configuring.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post-installation_configuration/coreos-layering.adoc
// * machine_configuration/coreos-layering.adoc
:_mod-docs-content-type: PROCEDURE
[id="coreos-layering-configuring_{context}"]

2
modules/coreos-layering-removing.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post-installation_configuration/coreos-layering.adoc
// * machine_configuration/coreos-layering.adoc
:_mod-docs-content-type: PROCEDURE
[id="coreos-layering-removing_{context}"]

2
modules/coreos-layering-updating.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post-installation_configuration/coreos-layering.adoc
// * machine_configuration/coreos-layering.adoc
:_mod-docs-content-type: REFERENCE
[id="coreos-layering-updating_{context}"]

2
modules/create-a-containerruntimeconfig-crd.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/machine-configs-custom.adoc
:_mod-docs-content-type: PROCEDURE
[id="create-a-containerruntimeconfig_{context}"]

2
modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc
View File

@@ -1,7 +1,7 @@
// Module included in the following assemblies:
//
// * post_installation_configuration/node-tasks.adoc
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/machine-configs-custom.adoc
:_mod-docs-content-type: PROCEDURE
[id="create-a-kubeletconfig-crd-to-edit-kubelet-parameters_{context}"]

2
modules/installation-special-config-chrony.adoc
View File

@@ -5,7 +5,7 @@
// * installing/installing_bare_metal/installing-restricted-networks-bare-metal.adoc
// * installing/installing_gcp/installing-restricted-networks-gcp.adoc
// * installing/installing_vsphere/installing-restricted-networks-vsphere.adoc
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/machine-configs-configure.adoc
ifeval::["{context}" == "installing-restricted-networks-bare-metal"]

6
modules/machine-config-daemon-metrics.adoc → modules/machine-config-daemon-metrics-understanding.adoc
View File

@@ -1,9 +1,9 @@
// Module included in the following assemblies:
//
// * nodes/nodes/nodes-nodes-machine-config-daemon-metrics.adoc
// * machine-config/machine-config-daemon-metrics.adoc
[id="machine-config-daemon-metrics_{context}"]
= Machine Config Daemon metrics
[id="machine-config-daemon-metrics-understanding_{context}"]
= Understanding Machine Config Daemon metrics
Beginning with {product-title} 4.3, the Machine Config Daemon provides a set of metrics. These metrics can be accessed using the Prometheus Cluster Monitoring stack.

2
modules/machine-config-drift-detection.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine-configuration/machine-configuration-tasks.adoc
:_mod-docs-content-type: CONCEPT
[id="machine-config-drift-detection_{context}"]

38
modules/machine-config-node-disruption.adoc → modules/machine-config-node-disruption-example.adoc
View File

@@ -3,44 +3,8 @@
// * post_installation_configuration/machine-configuration-tasks.adoc
:_mod-docs-content-type: PROCEDURE
[id="machine-config-node-disruption_{context}"]
= Understanding node restart behaviors after machine config changes
By default, when you make certain changes to the fields in a `MachineConfig` object, the Machine Config Operator (MCO) drains and reboots the nodes associated with that machine config. However, you can create a _node disruption policy_ that defines a set of changes to some Ignition config objects that would require little or no disruption to your workloads.
A node disruption policy allows you to define the configuration changes that cause a disruption to your cluster, and which changes do not. This allows you to reduce node downtime when making small machine configuration changes in your cluster. To configure the policy, you modify the `MachineConfiguration` object, which is in the `openshift-machine-config-operator` namespace. See the example node disruption policies in the `MachineConfiguration` objects that follow.
[NOTE]
====
There are machine configuration changes that always require a reboot, regardless of any node disruption policies. For more information, see _About the Machine Config Operator_.
====
After you create the node disruption policy, the MCO validates the policy to search for potential issues in the file, such as problems with formatting. The MCO then merges the policy with the cluster defaults and populates the `status.nodeDisruptionPolicyStatus` fields in the machine config with the actions to be performed upon future changes to the machine config. The configurations in your policy always overwrite the cluster defaults.
[IMPORTANT]
====
The MCO does not validate whether a change can be successfully applied by your node disruption policy. Therefore, you are responsible to ensure the accuracy of your node disruption policies.
====
For example, you can configure a node disruption policy so that sudo configurations do not require a node drain and reboot. Or, you can configure your cluster so that updates to `sshd` are applied with only a reload of that one service.
:FeatureName: The node disruption policy feature
include::snippets/technology-preview.adoc[]
You can control the behavior of the MCO when making the changes to the following Ignition configuration objects:
// I used this wording for the objects to match the previous section in the assembly: file:///home/mburke/openshift-docs/_preview/openshift-enterprise/mco-node-disruption-policy/post_installation_configuration/machine-configuration-tasks.html#what-can-you-change-with-machine-configs.
* *configuration files*: You add to or update the files in the `/var` or `/etc` directory.
* *systemd units*: You create and set the status of a systemd service or modify an existing systemd service.
* *users and groups*: You change SSH keys in the `passwd` section post-installation.
* *ICSP*, *ITMS*, *IDMS* objects: You can remove mirroring rules from an `ImageContentSourcePolicy` (ICSP), `ImageTagMirrorSet` (ITMS), and `ImageDigestMirrorSet` (IDMS) object.
include::snippets/machine-config-node-disruption-actions.adoc[]
// Examples taken from the test cases: https://polarion.engineering.redhat.com/polarion/#/project/OSE/workitems/testcase?query=trello%3AMCO%5C-507
[id="machine-config-node-disruption-example_{context}"]
== Example node disruption policies
= Example node disruption policies
The following example `MachineConfiguration` objects contain a node disruption policy.

6
modules/machine-config-operator.adoc
View File

@@ -1,7 +1,6 @@
// Module included in the following assemblies:
//
// * operators/operator-reference.adoc
// * post_installation_configuration/machine-configuration-tasks.adoc
[id="machine-config-operator_{context}"]
= Machine Config Operator
@@ -20,11 +19,8 @@ There are four components:
include::snippets/mcs-endpoint-limitation.adoc[]
.Additional resources
* xref:../networking/openshift_sdn/about-openshift-sdn.adoc#about-openshift-sdn[About the OpenShift SDN network plugin].
[discrete]
== Project
link:https://github.com/openshift/machine-config-operator[openshift-machine-config-operator]

6
modules/machine-config-overview.adoc
View File

@@ -1,7 +1,7 @@
// Module included in the following assemblies:
//
// * operators/operator-reference.adoc
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/index.adoc
:_mod-docs-content-type: CONCEPT
[id="machine-config-overview-{context}"]
@@ -77,7 +77,3 @@ include::snippets/node-icsp-no-drain.adoc[]
In other cases, you can mitigate the disruption to your workload when the MCO makes changes by using _node disruption policies_. For information, see _Understanding node restart behaviors after machine config changes_.
There might be situations where the configuration on a node does not fully match what the currently-applied machine config specifies. This state is called _configuration drift_. The Machine Config Daemon (MCD) regularly checks the nodes for configuration drift. If the MCD detects configuration drift, the MCO marks the node `degraded` until an administrator corrects the node configuration. A degraded node is online and operational, but, it cannot be updated. For more information on configuration drift, see _Understanding configuration drift detection_.
== Project
See the link:https://github.com/openshift/machine-config-operator[openshift-machine-config-operator] GitHub site for details.

3
modules/machineconfig-modify-journald.adoc
View File

@@ -1,7 +1,6 @@
// Module included in the following assemblies:
//
// * installing/post_installation_configuration/machine-configuration-tasks.adoc
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/machine-configs-configure.adoc
:_mod-docs-content-type: PROCEDURE
[id="machineconfig-modify-journald_{context}"]

116
modules/mco-update-boot-images-configuring.adoc Normal file
View File

@@ -0,0 +1,116 @@
// Module included in the following assemblies:
//
// * machine-configuration/mco-update-boot-images.adoc
// * nodes/nodes-nodes-managing.adoc
:_mod-docs-content-type: PROCEDURE
[id="mco-update-boot-images-configuring_{context}"]
= Configuring updated boot images
By default, {product-title} does not manage the boot image. You can configure your cluster to update the boot image whenever you update your cluster by modifying the `MachineConfiguration` object.
.Prerequisites
* You have enabled the `TechPreviewNoUpgrade` feature set by using the feature gates. For more information, see "Enabling features using feature gates" in the _Additional resources_ section.
.Procedure
. Edit the `MachineConfiguration` object, named `cluster`, to enable the updating of boot images by running the following command:
+
[source,terminal]
----
$ oc edit MachineConfiguration cluster
----
.. Optional: Configure the boot image update feature for all the machine sets:
+
[source,yaml]
----
apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
name: cluster
namespace: openshift-machine-config-operator
spec:
# ...
managedBootImages: <1>
machineManagers:
- resource: machinesets
apiGroup: machine.openshift.io
selection:
mode: All <2>
----
<1> Activates the boot image update feature.
<2> Specifies that all the machine sets in the cluster are to be updated.
.. Optional: Configure the boot image update feature for specific machine sets:
+
[source,yaml]
----
apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
name: cluster
namespace: openshift-machine-config-operator
spec:
# ...
managedBootImages: <1>
machineManagers:
- resource: machinesets
apiGroup: machine.openshift.io
selection:
mode: Partial
partial:
machineResourceSelector:
matchLabels:
update-boot-image: "true" <2>
----
<1> Activates the boot image update feature.
<2> Specifies that any machine set with this label is to be updated.
+
[TIP]
====
If an appropriate label is not present on the machine set, add a key/value pair by running a command similar to following:
----
$ oc label machineset.machine ci-ln-hmy310k-72292-5f87z-worker-a update-boot-image=true -n openshift-machine-api
----
====
.Verification
. Get the boot image version by running the following command:
+
[source,terminal]
----
$ oc get machinesets <machineset_name> -n openshift-machine-api -o yaml
----
+
.Example machine set with the boot image reference
+
[source,yaml]
----
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
labels:
machine.openshift.io/cluster-api-cluster: ci-ln-77hmkpt-72292-d4pxp
update-boot-image: "true"
name: ci-ln-77hmkpt-72292-d4pxp-worker-a
namespace: openshift-machine-api
spec:
# ...
template:
# ...
spec:
# ...
providerSpec:
# ...
value:
disks:
- autoDelete: true
boot: true
image: projects/rhcos-cloud/global/images/rhcos-416-92-202402201450-0-gcp-x86-64 <1>
# ...
----
<1> This boot image is the same as the current {product-title} version.

2
modules/nodes-clusters-cgroups-2.adoc
View File

@@ -1,7 +1,7 @@
// Module included in the following assemblies:
//
// * nodes/clusters/nodes-cluster-cgroups-2.adoc
// * post_installation_configuration/machine-configuration-tasks.adoc
// * post_installation_configuration/cluster-tasks.adoc
ifeval::["{context}" == "nodes-cluster-cgroups-2"]
:nodes:

2
modules/nodes-nodes-kernel-arguments.adoc
View File

@@ -1,7 +1,7 @@
// Module included in the following assemblies:
//
// * nodes/nodes-nodes-managing.adoc
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/machine-configs-configure.adoc
:_mod-docs-content-type: PROCEDURE
[id="nodes-nodes-kernel-arguments_{context}"]

2
modules/nodes-nodes-rtkernel-arguments.adoc
View File

@@ -1,7 +1,7 @@
// Module included in the following assemblies:
//
// * nodes/nodes/nodes-nodes-managing.adoc
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/machine-configs-configure.adoc
:_mod-docs-content-type: PROCEDURE
[id="nodes-nodes-rtkernel-arguments_{context}"]

2
modules/rhcos-add-extensions.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/machine-configs-configure.adoc
:_mod-docs-content-type: PROCEDURE
[id="rhcos-add-extensions_{context}"]

2
modules/rhcos-enabling-multipath-day-2.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/machine-configs-configure.adoc
:_mod-docs-content-type: PROCEDURE
[id="rhcos-enabling-multipath-day-2_{context}"]

2
modules/rhcos-load-firmware-blobs.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * post_installation_configuration/machine-configuration-tasks.adoc
// * machine_configuration/machine-configs-configure.adoc
:_mod-docs-content-type: PROCEDURE
[id="rhcos-load-firmware-blobs_{context}"]

2
modules/set-the-default-max-container-root-partition-size-for-overlay-with-crio.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// post_installation_configuration/machine-configuration-tasks.adoc
// machine_configuration/machine-configs-custom.adoc
:_mod-docs-content-type: PROCEDURE
[id="set-the-default-max-container-root-partition-size-for-overlay-with-crio_{context}"]

2
networking/ptp/about-ptp.adoc
View File

@@ -28,7 +28,7 @@ include::modules/nw-ptp-introduction.adoc[leveloffset=+1]
[IMPORTANT]
====
Before enabling PTP, ensure that NTP is disabled for the required nodes. You can disable the chrony time service (`chronyd`) using a `MachineConfig` custom resource. For more information, see xref:../../post_installation_configuration/machine-configuration-tasks.adoc#cnf-disable-chronyd_post-install-machine-configuration-tasks[Disabling chrony time service].
Before enabling PTP, ensure that NTP is disabled for the required nodes. You can disable the chrony time service (`chronyd`) using a `MachineConfig` custom resource. For more information, see xref:../../machine_configuration/machine-configs-configure.adoc#cnf-disable-chronyd_machine-configs-configure[Disabling chrony time service].
====
include::modules/ptp-dual-nics.adoc[leveloffset=+1]

2
nodes/containers/nodes-containers-using.adoc
View File

@@ -70,7 +70,7 @@ runC has some benefits over crun, including:
You can move between the two container runtimes as needed.
For information on setting which container runtime to use, see xref:../../post_installation_configuration/machine-configuration-tasks.adoc#create-a-containerruntimeconfig_post-install-machine-configuration-tasks[Creating a `ContainerRuntimeConfig` CR to edit CRI-O parameters].
For information on setting which container runtime to use, see xref:../../machine_configuration/machine-configs-custom.adoc#create-a-containerruntimeconfig_machine-configs-custom[Creating a `ContainerRuntimeConfig` CR to edit CRI-O parameters].
endif::openshift-rosa,openshift-dedicated[]
ifdef::openshift-rosa,openshift-dedicated[]

2
post_installation_configuration/ibmz-post-install.adoc
View File

@@ -23,7 +23,7 @@ The procedures described here apply only to z/VM installations. If you have inst
[role="_additional-resources"]
.Additional resources
* xref:../post_installation_configuration/machine-configuration-tasks.adoc#post-install-machine-configuration-tasks[Postinstallation machine configuration tasks]
* xref:../machine_configuration/index.adoc#machine-config-overview[Machine configuration overview]
include::modules/ibmz-configure-devices-mco.adoc[leveloffset=+1]

2
post_installation_configuration/index.adoc
View File

@@ -24,7 +24,7 @@ You can perform the post-installation configuration tasks to configure your envi
The following lists details these configurations:
* xref:../post_installation_configuration/machine-configuration-tasks.adoc#post-install-machine-configuration-tasks[Configure operating system features]: The Machine Config Operator (MCO) manages `MachineConfig` objects. By using the MCO, you can configure nodes and custom resources.
* xref:../machine_configuration/index.adoc#machine-config-overview[Configure operating system features]: The Machine Config Operator (MCO) manages `MachineConfig` objects. By using the MCO, you can configure nodes and custom resources.
* xref:../post_installation_configuration/bare-metal-configuration.adoc#post-install-bare-metal-configuration[Configure bare metal nodes]: You can use the Bare Metal Operator (BMO) to manage bare metal hosts. The BMO can complete the following operations:

6
post_installation_configuration/machine-configuration-tasks.adoc
View File

@@ -27,7 +27,7 @@ include::modules/machine-config-overview.adoc[leveloffset=+2]
.Additional resources
* xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-node-disruption_post-install-machine-configuration-tasks[Understanding node restart behaviors after machine config changes]
* xref:../machine_configuration/machine-config-node-disruption.adoc#machine-config-node-disruption[Understanding node restart behaviors after machine config changes]
include::modules/machine-config-drift-detection.adoc[leveloffset=+2]
include::modules/checking-mco-status.adoc[leveloffset=+2]
@@ -50,8 +50,6 @@ include::modules/machine-config-node-disruption.adoc[leveloffset=+1]
* xref:../architecture/control-plane.adoc#about-machine-config-operator_control-plane[About the Machine Config Operator]
include::modules/machine-config-node-disruption-config.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
@@ -64,7 +62,7 @@ You can use the tasks in this section to create `MachineConfig` objects that mod
{product-title} supports link:https://coreos.github.io/ignition/configuration-v3_2/[Ignition specification version 3.2]. All new machine configs you create going forward should be based on Ignition specification version 3.2. If you are upgrading your {product-title} cluster, any existing Ignition specification version 2.x machine configs will be translated automatically to specification version 3.2.
There might be situations where the configuration on a node does not fully match what the currently-applied machine config specifies. This state is called _configuration drift_. The Machine Config Daemon (MCD) regularly checks the nodes for configuration drift. If the MCD detects configuration drift, the MCO marks the node `degraded` until an administrator corrects the node configuration. A degraded node is online and operational, but, it cannot be updated. For more information on configuration drift, see xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-drift-detection_post-install-machine-configuration-tasks[Understanding configuration drift detection].
There might be situations where the configuration on a node does not fully match what the currently-applied machine config specifies. This state is called _configuration drift_. The Machine Config Daemon (MCD) regularly checks the nodes for configuration drift. If the MCD detects configuration drift, the MCO marks the node `degraded` until an administrator corrects the node configuration. A degraded node is online and operational, but, it cannot be updated. For more information on configuration drift, see xref:../machine_configuration/index.adoc#machine-config-drift-detection_machine-config-overview[Understanding configuration drift detection].
[TIP]
====

10
release_notes/ocp-4-16-release-notes.adoc
View File

@@ -1041,22 +1041,22 @@ To grant unauthenticated users access to the `system:webhook` role binding in sp
[id="ocp-4-16-machine-config-operator-gc_{context}"]
==== Garbage collection of unused rendered machine configs
With this release, you can now garbage collect unused rendered machine configs. By using the `oc adm prune renderedmachineconfigs` command, you can view the unused rendered machine configs, determine which to remove, then batch delete the rendered machine configs that you no longer need. Having too many machine configs can make working with the machine configs confusing and can also contribute to disk space and performance issues. For more information, see xref:../post_installation_configuration/machine-configuration-tasks.adoc#machineconfig-garbage-collect_post-install-machine-configuration-tasks[Managing unused rendered machine configs].
With this release, you can now garbage collect unused rendered machine configs. By using the `oc adm prune renderedmachineconfigs` command, you can view the unused rendered machine configs, determine which to remove, then batch delete the rendered machine configs that you no longer need. Having too many machine configs can make working with the machine configs confusing and can also contribute to disk space and performance issues. For more information, see xref:../machine_configuration/machine-configs-garbage-collection.adoc#machine-configs-garbage-collection[Managing unused rendered machine configs].
[id="ocp-4-16-machine-config-operator-node-disruption_{context}"]
==== Node disruption policies (Technology Preview)
By default, when you make certain changes to the parameters in a `MachineConfig` object, the Machine Config Operator (MCO) drains and reboots the nodes associated with that machine config. However, you can create a node disruption policy in the MCO namespace that defines a set of Ignition config objects changes that would require little or no disruption to your workloads. For more information, see xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-node-disruption_post-install-machine-configuration-tasks[Understanding node restart behaviors after machine config changes].
By default, when you make certain changes to the parameters in a `MachineConfig` object, the Machine Config Operator (MCO) drains and reboots the nodes associated with that machine config. However, you can create a node disruption policy in the MCO namespace that defines a set of Ignition config objects changes that would require little or no disruption to your workloads. For more information, see xref:../machine_configuration/machine-config-node-disruption.adoc#machine-config-node-disruption[Using node disruption policies to minimize disruption from machine config changes].
[id="ocp-4-16-machine-config-operator-on-cluster_{context}"]
==== On-cluster {op-system} image layering (Technology Preview)
With {op-system-first} image layering, you can now automatically build the custom layered image directly in your cluster, as a Technology Preview feature. Previously, you needed to build the custom layered image outside of the cluster, then pull the image into the cluster. You can use the image layering feature to extend the functionality of your base {op-system} image by layering additional images onto the base image. For more information, see xref:../post_installation_configuration/coreos-layering.adoc#coreos-layering[RHCOS image layering].
With {op-system-first} image layering, you can now automatically build the custom layered image directly in your cluster, as a Technology Preview feature. Previously, you needed to build the custom layered image outside of the cluster, then pull the image into the cluster. You can use the image layering feature to extend the functionality of your base {op-system} image by layering additional images onto the base image. For more information, see xref:../machine_configuration/mco-coreos-layering.adoc#mco-coreos-layering[RHCOS image layering].
[id="ocp-4-16-machine-config-operator-boot-image_{context}"]
==== Updating boot images (Technology Preview)
By default, the MCO does not delete the boot image it uses to bring up a {op-system-first} node. Consequently, the boot image in your cluster is not updated along with your cluster. You can now configure your cluster to update the boot image whenever you update your cluster. For more information, see xref:../post_installation_configuration/machine-configuration-tasks.adoc#mco-update-boot-images_post-install-machine-configuration-tasks[Updating boot images].
By default, the MCO does not delete the boot image it uses to bring up a {op-system-first} node. Consequently, the boot image in your cluster is not updated along with your cluster. You can now configure your cluster to update the boot image whenever you update your cluster. For more information, see xref:../machine_configuration/mco-update-boot-images.adoc#mco-update-boot-images[Updating boot images].
[id="ocp-4-16-machine-management_{context}"]
=== Machine management
@@ -1725,7 +1725,7 @@ With this release, installation of package-based {op-system-base} worker nodes i
{op-system} image layering will replace this feature and supports installing additional packages on the base operating system of your worker nodes.
For more information about image layering, see xref:../post_installation_configuration/coreos-layering.adoc[{op-system} image layering].
For more information about image layering, see xref:../machine_configuration/mco-coreos-layering.adoc#mco-coreos-layering[{op-system} image layering].
[id="ocp-4-16-deprecation-operator-sdk_{context}"]
==== Operator SDK CLI tool and related testing and scaffolding tools are deprecated

2
security/certificate_types_descriptions/machine-config-operator-certificates.adoc
View File

@@ -25,7 +25,7 @@ include::snippets/mcs-endpoint-limitation.adoc[]
.Additional resources
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#understanding-the-machine-config-operator[Understanding the Machine Config Operator].
* xref:../../machine_configuration/index.adoc#machine-config-operator_machine-config-overview[Machine Config Operator].
* xref:../../networking/openshift_sdn/about-openshift-sdn.adoc#about-openshift-sdn[About the OpenShift SDN network plugin].

2
security/container_security/security-container-signature.adoc
View File

@@ -33,4 +33,4 @@ include::modules/containers-signature-verify-skopeo.adoc[leveloffset=+2]
[id="additional-resources_security-container-signature"]
[role="_additional-resources"]
== Additional resources
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-overview-post-install-machine-configuration-tasks[Machine Config Overview]
* xref:../../machine_configuration/index.adoc#machine-config-overview[Machine Config Overview]

2
security/seccomp-profiles.adoc
View File

@@ -52,4 +52,4 @@ The custom SCC must have the appropriate priority to be automatically assigned t
[role="_additional-resources"]
== Additional resources
* xref:../authentication/managing-security-context-constraints.adoc[Managing security context constraints]
* xref:../post_installation_configuration/machine-configuration-tasks.adoc[Postinstallation machine configuration tasks]
* xref:../machine_configuration/index.adoc#machine-config-overview[Machine Config Overview]

4
support/troubleshooting/troubleshooting-network-issues.adoc
View File

@@ -21,8 +21,8 @@ include::modules/configuring-ovs-log-level-permanently.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#understanding-the-machine-config-operator[Understanding the Machine Config Operator]
* xref:../../machine_configuration/index.adoc#machine-config-operator_machine-config-overview[Understanding the Machine Config Operator]
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#checking-mco-status_post-install-machine-configuration-tasks[Checking machine config pool status]
* xref:../../machine_configuration/index.adoc#checking-mco-status_machine-config-overview[Checking machine config pool status]
include::modules/displaying-ovs-logs.adoc[leveloffset=+2]

2
updating/understanding_updates/how-updates-work.adoc
View File

@@ -42,4 +42,4 @@ include::modules/update-mco-process.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-overview-post-install-machine-configuration-tasks[Machine config overview]
* xref:../../machine_configuration/index.adoc#machine-config-overview[Machine Config Overview]

2
updating/understanding_updates/intro-to-updates.adoc
View File

@@ -55,7 +55,7 @@ include::modules/update-common-terms.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-overview-post-install-machine-configuration-tasks[Machine config overview]
* xref:../../machine_configuration/index.adoc#machine-config-overview[Machine Config Overview]
ifdef::openshift-enterprise[]
* xref:../../updating/updating_a_cluster/updating_disconnected_cluster/disconnected-update-osus.adoc#update-service-overview_updating-restricted-network-cluster-osus[Using the OpenShift Update Service in a disconnected environment]
* xref:../../updating/understanding_updates/understanding-update-channels-release.adoc#understanding-update-channels_understanding-update-channels-releases[Update channels]

4
updating/understanding_updates/understanding-openshift-update-duration.adoc
View File

@@ -33,7 +33,7 @@ include::modules/update-duration-mco.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* xref:../../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-overview-post-install-machine-configuration-tasks[Machine config overview]
* xref:../../machine_configuration/index.adoc#machine-config-overview[Machine Config Overview]
* xref:../../nodes/pods/nodes-pods-configuring.adoc#nodes-pods-configuring-pod-distruption-about_nodes-pods-configuring[Pod disruption budget]
//Example update duration of cluster Operators
@@ -63,4 +63,4 @@ endif::openshift-origin[]
== Additional resources
* xref:../../architecture/architecture.adoc#architecture[OpenShift Container Platform architecture]
* xref:../../updating/understanding_updates/intro-to-updates.adoc#understanding-openshift-updates[OpenShift Container Platform updates]
* xref:../../updating/understanding_updates/intro-to-updates.adoc#understanding-openshift-updates[OpenShift Container Platform updates]

2
updating/updating_a_cluster/updating_disconnected_cluster/disconnected-update.adoc
View File

@@ -69,4 +69,4 @@ include::modules/generating-icsp-object-scoped-to-a-registry.adoc[leveloffset=+1
* xref:../../../operators/admin/olm-restricted-networks.adoc#olm-restricted-networks[Using Operator Lifecycle Manager on restricted networks]
* xref:../../../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-overview-post-install-machine-configuration-tasks[Machine Config Overview]
* xref:../../../machine_configuration/index.adoc#machine-config-overview[Machine Config Overview]

2
virt/monitoring/virt-prometheus-queries.adoc
View File

@@ -20,7 +20,7 @@ endif::openshift-rosa,openshift-dedicated[]
// Hiding in ROSA/OSD as user cannot edit MCO
ifndef::openshift-rosa,openshift-dedicated[]
* To use the vCPU metric, the `schedstats=enable` kernel argument must be applied to the `MachineConfig` object. This kernel argument enables scheduler statistics used for debugging and performance tuning and adds a minor additional load to the scheduler. For more information, see xref:../../post_installation_configuration/machine-configuration-tasks.adoc#nodes-nodes-kernel-arguments_post-install-machine-configuration-tasks[Adding kernel arguments to nodes].
* To use the vCPU metric, the `schedstats=enable` kernel argument must be applied to the `MachineConfig` object. This kernel argument enables scheduler statistics used for debugging and performance tuning and adds a minor additional load to the scheduler. For more information, see xref:../../machine_configuration/machine-configs-configure.adoc#nodes-nodes-kernel-arguments_machine-configs-configure[Adding kernel arguments to nodes].
endif::openshift-rosa,openshift-dedicated[]
* For guest memory swapping queries to return data, memory swapping must be enabled on the virtual guests.

2
virt/virtual_machines/advanced_vm_management/virt-configuring-pci-passthrough.adoc
View File

@@ -49,4 +49,4 @@ include::modules/virt-assigning-pci-device-virtual-machine.adoc[leveloffset=+2]
== Additional resources
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-troubleshooting-enabling_intel_vt_x_and_amd_v_virtualization_hardware_extensions_in_bios[Enabling Intel VT-X and AMD-V Virtualization Hardware Extensions in BIOS]
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_managing-file-permissions_configuring-basic-system-settings[Managing file permissions]
* xref:../../../post_installation_configuration/machine-configuration-tasks.adoc#post-install-machine-configuration-tasks[Postinstallation machine configuration tasks]
* xref:../../../machine_configuration/index.adoc#machine-config-overview[Machine Config Overview]

2
welcome/index.adoc
View File

@@ -154,7 +154,7 @@ xref:../installing/installing_ibm_cloud_public/preparing-to-install-on-ibm-cloud
- **xref:../storage/persistent_storage/persistent-storage-ocs.adoc#red-hat-openshift-data-foundation[Install Red Hat OpenShift Data Foundation]**: You can install {rh-storage-first} as an Operator to provide highly integrated and simplified persistent storage management for containers.
- **xref:../post_installation_configuration/coreos-layering.adoc#coreos-layering[{op-system-first} image layering]**: As a post-installation task, you can add new images on top of the base {op-system} image. This layering does not modify the base {op-system} image. Instead, the layering creates a custom layered image that includes all {op-system} functions and adds additional functions to specific nodes in the cluster.
- **xref:../machine_configuration/mco-coreos-layering.adoc#mco-coreos-layering[{op-system-first} image layering]**: As a post-installation task, you can add new images on top of the base {op-system} image. This layering does not modify the base {op-system} image. Instead, the layering creates a custom layered image that includes all {op-system} functions and adds additional functions to specific nodes in the cluster.
endif::[]
ifndef::openshift-rosa,openshift-dedicated,openshift-dpu,microshift[]

2
welcome/learn_more_about_openshift.adoc
View File

@@ -46,7 +46,7 @@ Use the following sections to find content to help you learn about and use {prod
| xref:../support/getting-support.adoc#getting-support[Getting Support]
| xref:../architecture/architecture.adoc#architecture[Architecture]
| xref:../post_installation_configuration/machine-configuration-tasks.adoc#post-install-machine-configuration-tasks[Post installation configuration]
| xref:../machine_configuration/index.adoc#machine-config-overview[Machine configuration overview]
| xref:../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
| link:https://access.redhat.com/articles/4217411[OpenShift Knowledgebase articles]