Validation fixes (suse-edge#320)

* Headlines in Appendix need to be Level 1

* SEO improvement: replacing underscores with dashes in IDs

Author: fsundermeyer

asciidoc/components/networking.adoc

@@ -65,7 +65,7 @@ The EIB container image is publicly available and can be downloaded from the SUS
 podman pull registry.suse.com/edge/edge-image-builder:1.0.2
 ----
 
-=== Creating the image configuration directory [[config_dir_creation]]
+=== Creating the image configuration directory [[image-config-dir-creation]]
 
 Let's start with creating the configuration directory:
 
@@ -128,7 +128,7 @@ The configuration directory at this point should look like the following:
     └── SLE-Micro.x86_64-5.5.0-Default-GM.raw
 ----
 
-=== Defining the network configurations [[default_network_definition]]
+=== Defining the network configurations [[default-network-definition]]
 
 The desired network configurations are not part of the image definition file that we just created.
 We'll now populate those under the special `network/` directory. Let's create it:
@@ -705,7 +705,7 @@ Wired Connection  300ed658-08d4-4281-9f8c-d1b8882d29b9  ethernet  eth0    /var/r
 There are occasions where relying on known MAC addresses is not an option. In these cases we can opt for the so-called _unified configuration_
 which allows us to specify settings in an `_all.yaml` file which will then be applied across all provisioned nodes.
 
-We will build and provision an edge node using different configuration structure. Follow all steps starting from <<config_dir_creation>> up until <<default_network_definition>>.
+We will build and provision an edge node using different configuration structure. Follow all steps starting from <<image-config-dir-creation>> up until <<default-network-definition>>.
 
 In this example we define a desired state of two Ethernet interfaces (eth0 and eth1) - one using DHCP, and one assigned a static IP address.
 
@@ -856,7 +856,7 @@ its limitation stems from the fact that using it is much less convenient when bo
 > NOTE: It is recommended to use the default network configuration via files describing the desired network states under the `/network` directory.
 Only opt for custom scripting when that behaviour is not applicable to your use case.
 
-We will build and provision an edge node using different configuration structure. Follow all steps starting from <<config_dir_creation>> up until <<default_network_definition>>.
+We will build and provision an edge node using different configuration structure. Follow all steps starting from <<image-config-dir-creation>> up until <<default-network-definition>>.
 
 In this example, we will create a custom script which applies static configuration for the `eth0` interface on all provisioned nodes,
 as well as removing and disabling the automatically created wired connections by NetworkManager. This is beneficial in situations where you want to make sure that every node in your cluster has an identical networking configuration, and as such you do not need to be concerned with the MAC address of each node prior to image creation.

asciidoc/day2/downstream-cluster-helm.adoc

@@ -187,7 +187,7 @@ For K3s, see link:https://docs.k3s.io/installation/registry-mirror[Embedded Regi
 
 [NOTE]
 ====
-The below upgrade procedure utilises Rancher's <<components-fleet,Fleet>> funtionality. Users using a third-party GitOps workflow should retrieve the chart versions supported by each Edge release from the <<release_notes>> and populate these versions to their third-party GitOps workflow.
+The below upgrade procedure utilises Rancher's <<components-fleet,Fleet>> funtionality. Users using a third-party GitOps workflow should retrieve the chart versions supported by each Edge release from the <<release-notes>> and populate these versions to their third-party GitOps workflow.
 ====
 
 This section focuses on the following Helm upgrade procedure use-cases:
@@ -321,9 +321,9 @@ Once deployed with Fleet, for Helm chart upgrades, see <<day2-helm-upgrade-fleet
 [#day2-helm-upgrade-fleet-managed-chart]
 ==== I would like to upgrade a Fleet managed Helm chart
 
-. Determine the version to which you need to upgrade your chart so that it is compatible with an Edge 3.X.Y release. Helm chart version per Edge release can be viewed from the <<release_notes>>.
+. Determine the version to which you need to upgrade your chart so that it is compatible with an Edge 3.X.Y release. Helm chart version per Edge release can be viewed from the <<release-notes>>.
 
-. In your Fleet monitored Git repository, edit the Helm chart's `fleet.yaml` file with the correct chart *version* and *repository* from the <<release_notes>>.
+. In your Fleet monitored Git repository, edit the Helm chart's `fleet.yaml` file with the correct chart *version* and *repository* from the <<release-notes>>.
 
 . After commiting and pushing the changes to your repository, this will trigger an upgrade of the desired Helm chart
 
@@ -493,7 +493,7 @@ Executing this steps should result in a successfully created `GitRepo` resource.
 
 Fleet will then deploy all the Kubernetes resources from the Bundle to the specified downstream clusters. One of this resources will be a SUC Plan that will trigger the chart upgrade. For a full list of the resoruces that will be deployed and the workflow of the upgrade process, refer to the <<day2-helm-upgrade-eib-chart-overview, overview>> section.
 
-To track the upgrade process itself, refer to the <<monitor_suc_plans, Monitor SUC Plans>> section.
+To track the upgrade process itself, refer to the <<monitor-suc-plans, Monitor SUC Plans>> section.
 
 [#day2-helm-upgrade-eib-chart-example]
 ===== Example
@@ -681,7 +681,7 @@ image::day2_helm_chart_upgrade_example_gitrepo.png[]
 
 Now we need to monitor the upgrade procedures on the clusters:
 
-. Check the status of the *Upgrade Pods*, following the directions from the <<monitor_suc_plans, SUC plan monitor>> section.
+. Check the status of the *Upgrade Pods*, following the directions from the <<monitor-suc-plans, SUC plan monitor>> section.
 
 .. A successfully completed *Upgrade Pod* that has been working on an `intialiser` node should hold logs similar to:
 +

asciidoc/day2/downstream-cluster-k8s.adoc

@@ -144,7 +144,7 @@ Kubernetes version upgrade steps:
 The above *SUC Plans* will be deployed in the `cattle-system` namespace of each downstream cluster.
 ====
 
-. On the downstream cluster, *SUC* picks up the newly deployed *SUC Plans* and deploys an *_Update Pod_* on each node that matches the *node selector* defined in the *SUC Plan*. For information how to monitor the *SUC Plan Pod*, refer to <<monitor_suc_plans>>.
+. On the downstream cluster, *SUC* picks up the newly deployed *SUC Plans* and deploys an *_Update Pod_* on each node that matches the *node selector* defined in the *SUC Plan*. For information how to monitor the *SUC Plan Pod*, refer to <<monitor-suc-plans>>.
 
 . Depending on which *SUC Plans* you have deployed, the *Update Pod* will run either a https://hub.docker.com/r/rancher/rke2-upgrade/tags[rke2-upgrade] or a https://hub.docker.com/r/rancher/k3s-upgrade/tags[k3s-upgrade] image and will execute the following workflow on *each* cluster node:
 
@@ -175,7 +175,7 @@ A *GitRepo* resource, that ships the needed `Kubernetes upgrade` *SUC Plans*, ca
 
 . By <<k8s-upgrade-suc-plan-deployment-git-repo-manual, manually deploying>> the resource to your `management cluster`.
 
-Once deployed, to monitor the Kubernetes upgrade process of the nodes of your targeted cluster, refer to the <<monitor_suc_plans>> documentation.
+Once deployed, to monitor the Kubernetes upgrade process of the nodes of your targeted cluster, refer to the <<monitor-suc-plans>> documentation.
 
 [#k8s-upgrade-suc-plan-deployment-git-repo-rancher]
 ===== GitRepo creation - Rancher UI
@@ -273,7 +273,7 @@ A *Bundle* resource, that ships the needed `Kubernetes upgrade` *SUC Plans*, can
 
 . By <<k8s-upgrade-suc-plan-deployment-bundle-manual, manually deploying>> the resource to your `management cluster`.
 
-Once deployed, to monitor the Kubernetes upgrade process of the nodes of your targeted cluster, refer to the <<monitor_suc_plans>> documentation.
+Once deployed, to monitor the Kubernetes upgrade process of the nodes of your targeted cluster, refer to the <<monitor-suc-plans>> documentation.
 
 [#k8s-upgrade-suc-plan-deployment-bundle-rancher]
 ===== Bundle creation - Rancher UI

asciidoc/day2/downstream-cluster-os.adoc

@@ -133,7 +133,7 @@ OS pacakge update steps:
 The above resources will be deployed in the `cattle-system` namespace of each downstream cluster.
 ====
 
-. On the downstream cluster, *SUC* picks up the newly deployed *SUC Plans* and deploys an *_Update Pod_* on each node that matches the *node selector* defined in the *SUC Plan*. For information how to monitor the *SUC Plan Pod*, refer to <<monitor_suc_plans>>.
+. On the downstream cluster, *SUC* picks up the newly deployed *SUC Plans* and deploys an *_Update Pod_* on each node that matches the *node selector* defined in the *SUC Plan*. For information how to monitor the *SUC Plan Pod*, refer to <<monitor-suc-plans>>.
 
 . The *Update Pod* (deployed on each node) *mounts* the `os-pkg-update` Secret and *executes* the `update.sh` script that the Secret ships.
 
@@ -175,7 +175,7 @@ A *GitRepo* resource, that ships the needed `OS package update` *SUC Plans*, can
 
 . By <<os-pkg-suc-plan-deployment-git-repo-manual, manually deploying>> the resource to your `management cluster`.
 
-Once deployed, to monitor the OS package update process of the nodes of your targeted cluster, refer to the <<monitor_suc_plans>> documentation.
+Once deployed, to monitor the OS package update process of the nodes of your targeted cluster, refer to the <<monitor-suc-plans>> documentation.
 
 [#os-pkg-suc-plan-deployment-git-repo-rancher]
 ===== GitRepo creation - Rancher UI
@@ -251,7 +251,7 @@ A *Bundle* resource, that ships the needed `OS package update` *SUC Plans*, can
 
 . By <<os-pkg-suc-plan-deployment-bundle-manual, manually deploying>> the resource to your `management cluster`.
 
-Once deployed, to monitor the OS package update process of the nodes of your targeted cluster, refer to the <<monitor_suc_plans>> documentation.
+Once deployed, to monitor the OS package update process of the nodes of your targeted cluster, refer to the <<monitor-suc-plans>> documentation.
 
 [#os-pkg-suc-plan-deployment-bundle-rancher]
 ===== Bundle creation - Rancher UI

asciidoc/day2/downstream-cluster-suc.adoc

@@ -50,7 +50,7 @@ If using the `suse-edge/fleet-examples` repository, make sure you are using the
 
 * By <<day2-suc-dep-gitrepo-manual, manually deploying>> the resources to your `management cluster`
 
-Once created, `Fleet` will be responsible for picking up the resource and deploying the *SUC* resources to all your *target* clusters. For information on how to track the deployment process, see <<monitor_suc_deployment>>.
+Once created, `Fleet` will be responsible for picking up the resource and deploying the *SUC* resources to all your *target* clusters. For information on how to track the deployment process, see <<monitor-suc-deployment>>.
 
 [#day2-suc-dep-gitrepo-rancher]
 ===== GitRepo deployment - Rancher UI
@@ -134,7 +134,7 @@ If using the `suse-edge/fleet-examples` repository, make sure you are using the
 
 * By <<day2-suc-dep-bundle-manual, manually deploying>> the resources to your `management cluster`
 
-Once created, `Fleet` will be responsible for pickuping the resource and deploying the *SUC* resources to all your *target* clusters. For information on how to track the deployment process, see <<monitor_suc_deployment>>.
+Once created, `Fleet` will be responsible for pickuping the resource and deploying the *SUC* resources to all your *target* clusters. For information on how to track the deployment process, see <<monitor-suc-deployment>>.
 
 [#day2-suc-dep-bundle-rancher]
 ===== Bundle creation - Rancher UI
@@ -226,7 +226,7 @@ Use the above mentioned resoruces to populate the data that your third-party Git
 
 This section covers how to monitor the lifecycle of the *SUC* deployment and any deployed *SUC* Plans using the Rancher UI.
 
-[#monitor_suc_deployment]
+[#monitor-suc-deployment]
 ==== Monitor SUC deployment
 
 To check the *SUC* pod logs for a specific cluster:
@@ -250,7 +250,7 @@ image::day2-monitor-suc-deployment-2.png[]
 +
 image::day2-monitor-suc-deployment-3.png[]
 
-[#monitor_suc_plans]
+[#monitor-suc-plans]
 ==== Monitor SUC Plans
 
 [IMPORTANT]

asciidoc/day2/downstream-clusters-introduction.adoc

@@ -56,7 +56,7 @@ For use-cases, where a third party GitOps tool usage is desired, see:
 
 . For `Kubernetes distribution upgrades` - <<k8s-upgrade-suc-plan-deployment-third-party>>
 
-. For `Helm chart upgrades` - retrieve the chart version supported by the desired Edge release from the <<release_notes>> page and populate the chart version and URL in your third party GitOps tool
+. For `Helm chart upgrades` - retrieve the chart version supported by the desired Edge release from the <<release-notes>> page and populate the chart version and URL in your third party GitOps tool
 ====
 
 ==== System-upgrade-controller (SUC)

asciidoc/edge-book/edge.adoc

@@ -146,8 +146,7 @@ include::../product/atip-lifecycle.adoc[]
 //--------------------------------------------
 
 [appendix]
-
-= Release Notes
+== Release Notes
 
 //--------------------------------------------
 // Release Notes

asciidoc/edge-book/releasenotes.adoc

@@ -1,4 +1,4 @@
-[#release_notes]
+[#release-notes]
 
 = Abstract
 ifdef::env-github[]