Merge pull request #29342 from bgilbert/fixes

Fix Ignition doc links, spec versions, some wording

Author: vikram-redhat

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

@@ -7,7 +7,7 @@
 [id="create-a-kubeletconfig-crd-to-edit-kubelet-parameters_{context}"]
 = Creating a `KubeletConfig` CRD to edit kubelet parameters
 
-The kubelet configuration is currently serialized as an ignition configuration, so it can be directly edited. However, there is also a new
+The kubelet configuration is currently serialized as an Ignition configuration, so it can be directly edited. However, there is also a new
 `kubelet-config-controller` added to the Machine Config Controller (MCC). This allows you to create a `KubeletConfig` custom resource (CR) to edit the kubelet parameters.
 
 .Procedure

modules/ignition-config-viewing.adoc

@@ -71,7 +71,7 @@ config from the bootstrap machine:
 Here are a few things you can learn from the `bootstrap.ign` file: +
 
 * Format: The format of the file is defined in the
-https://github.com/coreos/ignition/tree/spec2x[Ignition config spec].
+https://coreos.github.io/ignition/configuration-v3_2/[Ignition config spec].
 Files of the same format are used later by the MCO to merge changes into a
 machine’s configuration.
 * Contents: Because the bootstrap machine serves the Ignition configs for other

modules/installation-azure-user-infra-uploading-rhcos.adoc

@@ -3,11 +3,11 @@
 // * installing/installing_gcp/installing-azure-user-infra.adoc
 
 [id="installation-azure-user-infra-uploading-rhcos_{context}"]
-= Uploading the {op-system} cluster image and bootstrap ignition config file
+= Uploading the {op-system} cluster image and bootstrap Ignition config file
 
 The Azure client does not support deployments based on files existing locally;
 therefore, you must copy and store the {op-system} virtual hard disk (VHD)
-cluster image and bootstrap ignition config file in a storage container so they
+cluster image and bootstrap Ignition config file in a storage container so they
 are accessible during deployment.
 
 .Prerequisites

modules/installation-osp-converting-ignition-resources.adoc

@@ -15,7 +15,7 @@ Edit the file and upload it. Then, create a secondary bootstrap Ignition configu
 * You have the bootstrap Ignition file that the installer program generates, `bootstrap.ign`.
 * The infrastructure ID from the installer's metadata file is set as an environment variable (`$INFRA_ID`).
 ** If the variable is not set, see *Creating the Kubernetes manifest and Ignition config files*.
-* You have an HTTP(S)-accessible way to store the bootstrap ignition file.
+* You have an HTTP(S)-accessible way to store the bootstrap Ignition file.
 ** The documented procedure uses the {rh-openstack} image service (Glance), but you can also use the {rh-openstack} storage service (Swift), Amazon S3, an internal HTTP server, or an ad hoc Nova server.
 
 .Procedure

modules/installation-rhv-about-inventory-yml.adoc

@@ -170,7 +170,7 @@ You can override the value a virtual machine inherits from its profile. To do th
 
 .Metadata variables
 
-For virtual machines, `metadata.infraID` prepends the name of the virtual machine with the infrastructure ID from the `metadata.json` file you create when you build the ignition files.
+For virtual machines, `metadata.infraID` prepends the name of the virtual machine with the infrastructure ID from the `metadata.json` file you create when you build the Ignition files.
 
 The playbooks use the following code to read `infraID` from the specific file located in the `ocp.assets_dir`.
 

modules/installation-rhv-building-ignition-files.adoc

@@ -3,7 +3,7 @@
 // * installing/installing_rhv/installing-rhv-user-infra.adoc
 
 [id="installation-rhv-building-ignition-files_{context}"]
-= Building the ignition files
+= Building the Ignition files
 
 To build the Ignition files from the manifest files you just generated and modified, you run the installation program. This action creates a {op-system-first} machine, `initramfs`, which fetches the Ignition files and performs the configurations needed to create a node.
 

modules/investigating-master-node-installation-issues.adoc

@@ -36,7 +36,7 @@ $ curl -I http://<http_server_fqdn>:<port>/master.ign  <1>
 ----
 <1> The `-I` option returns the header only. If the Ignition file is available on the specified URL, the command returns `200 OK` status. If it is not available, the command returns `404 file not found`.
 +
-.. To verify that the ignition file was received by the master node, query the HTTP server logs on the serving host. For example, if you are using an Apache web server to serve Ignition files:
+.. To verify that the Ignition file was received by the master node, query the HTTP server logs on the serving host. For example, if you are using an Apache web server to serve Ignition files:
 +
 [source,terminal]
 ----

modules/investigating-worker-node-installation-issues.adoc

@@ -36,7 +36,7 @@ $ curl -I http://<http_server_fqdn>:<port>/worker.ign  <1>
 ----
 <1> The `-I` option returns the header only. If the Ignition file is available on the specified URL, the command returns `200 OK` status. If it is not available, the command returns `404 file not found`.
 +
-.. To verify that the ignition file was received by the worker node, query the HTTP server logs on the HTTP host. For example, if you are using an Apache web server to serve Ignition files:
+.. To verify that the Ignition file was received by the worker node, query the HTTP server logs on the HTTP host. For example, if you are using an Apache web server to serve Ignition files:
 +
 [source,terminal]
 ----

modules/machine-config-overview.adoc

@@ -21,7 +21,7 @@ a machine config that is injected directly into the {product-title} installer pr
 
 * MCO is only supported for writing to files in `/etc` and `/var` directories, although there are symbolic links to some directories that can be writeable by being symbolically linked to one of those areas. The `/opt` directory is an example.
 
-* Ignition is the configuration format used in MachineConfigs. See the link:https://github.com/coreos/ignition/blob/master/docs/configuration-v3_1.md[Ignition Configuration Specification v3.1.0] for details.
+* Ignition is the configuration format used in MachineConfigs. See the link:https://coreos.github.io/ignition/configuration-v3_2/[Ignition Configuration Specification v3.2.0] for details.
 
 * Although Ignition config settings can be delivered directly at {product-title} installation time, and are formatted in the same way that MCO delivers Ignition configs, MCO has no way of seeing what those original Ignition configs are. Therefore, you should wrap Ignition config settings into a machine config before deploying them.
 
@@ -30,12 +30,12 @@ offending file, however, and should continue to operate in a `degraded` state.
 
 * A key reason for using a machine config is that it will be applied when you spin up new nodes for a pool in your {product-title} cluster. The `machine-api-operator` provisions a new machine and MCO configures it.
 
-MCO uses link:https://github.com/coreos/ignition[CoreOS Ignition] as the configuration format {product-title} 4.6 moved from Ignition version 2 to Ignition version 3 format.
+MCO uses link:https://coreos.github.io/ignition/[Ignition] as the configuration format. {product-title} 4.6 moved from Ignition config specification version 2 to version 3.
 
 == What can you change with machine configs?
 The kinds of components that MCO can change include:
 
-* **config**: Create ignition config objects (see the link:https://github.com/coreos/ignition/blob/master/docs/configuration-v3_1.md[Ignition configuration specification]) to do things like modify files, systemd services, and other features on {product-title} machines, including:
+* **config**: Create Ignition config objects (see the link:https://coreos.github.io/ignition/configuration-v3_2/[Ignition configuration specification]) to do things like modify files, systemd services, and other features on {product-title} machines, including:
 - **Configuration files**: Create or overwrite files in the `/var` or `/etc` directory.
 - **systemd units**: Create and set the status of a systemd service or add to an existing systemd service by dropping in additional settings.
 - **users and groups**: Change ssh keys in the passwd section post-installation.

post_installation_configuration/machine-configuration-tasks.adoc

@@ -24,7 +24,7 @@ Tasks in this section let you create `MachineConfig` objects to modify files, sy
  content related to link:https://access.redhat.com/solutions/5307301[changing MTU network settings], link:https://access.redhat.com/solutions/5096731[adding] or
 link:https://access.redhat.com/solutions/4510281[updating] SSH authorized keys, link:https://access.redhat.com/solutions/4518671[replacing DNS nameservers], 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} version 4.7 supports link:https://github.com/coreos/ignition/blob/master/docs/configuration-v3_1.md[Ignition specification version 3.1].  All new machine configs you create going forward should be based on Ignition specification version 3.1.  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.1.
+{product-title} version 4.7 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.
 
 include::modules/installation-special-config-crony.adoc[leveloffset=+2]
 include::modules/nodes-nodes-kernel-arguments.adoc[leveloffset=+2]