OSDOCS#15507: Removing discrete headings in core OCP docs

migrating_from_ocp_3_to_4/advanced-migration-options-3-4.adoc

@@ -32,7 +32,7 @@ include::modules/migration-state-migration-cli.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 [id="additional-resources-for-state-migration_{context}"]
-[discrete]
+
 === Additional resources
 
 * See xref:../migrating_from_ocp_3_to_4/advanced-migration-options-3-4.adoc#migration-excluding-pvcs_advanced-migration-options-3-4[Excluding PVCs from migration] to select PVCs for state migration.
@@ -55,7 +55,7 @@ include::modules/migration-editing-pvs-in-migplan.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 [id="additional-resources-for-editing-pv-attributes_{context}"]
-[discrete]
+
 ==== Additional resources
 
 * For details about the `move` and `copy` actions, see xref:../migrating_from_ocp_3_to_4/about-mtc-3-4.adoc#migration-mtc-workflow_about-mtc-3-4[MTC workflow].

migrating_from_ocp_3_to_4/migrating-applications-3-4.adoc

@@ -32,7 +32,7 @@ These annotations preserve the UID range, ensuring that the containers retain th
 include::modules/migration-prerequisites.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
-[discrete]
+
 [id="additional-resources-for-migration-prerequisites_{context}"]
 === Additional resources for migration prerequisites
 
@@ -50,7 +50,7 @@ include::modules/migration-adding-replication-repository-to-cam.adoc[leveloffset
 include::modules/migration-creating-migration-plan-cam.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
-[discrete]
+
 [id="additional-resources-for-persistent-volume-copy-methods_{context}"]
 === Additional resources
 

migrating_from_ocp_3_to_4/planning-migration-3-4.adoc

@@ -25,7 +25,7 @@ Beginning with {product-title} 4.13, {op-system} now uses {op-system-base-full}
 
 For more information, see xref:../architecture/architecture.adoc#architecture[OpenShift Container Platform architecture].
 
-[discrete]
+
 === Immutable infrastructure
 
 {product-title} 4 uses {op-system-first}, which is designed to run containerized applications, and provides efficient installation, Operator-based management, and simplified upgrades. {op-system} is an immutable container host, rather than a customizable operating system like {op-system-base}. {op-system} enables {product-title} 4 to manage and automate the deployment of the underlying container host. {op-system} is a part of {product-title}, which means that everything runs inside a container and is deployed using {product-title}.
@@ -34,7 +34,7 @@ In {product-title} 4, control plane nodes must run {op-system}, ensuring that fu
 
 For more information, see xref:../architecture/architecture-rhcos.adoc#architecture-rhcos[{op-system-first}].
 
-[discrete]
+
 === Operators
 
 Operators are a method of packaging, deploying, and managing a Kubernetes application. Operators ease the operational complexity of running another piece of software. They watch over your environment and use the current state to make decisions in real time. Advanced Operators are designed to upgrade and react to failures automatically.
@@ -44,7 +44,7 @@ For more information, see xref:../operators/understanding/olm-what-operators-are
 [id="migration-differences-install"]
 == Installation and upgrade
 
-[discrete]
+
 === Installation process
 
 To install {product-title} 3.11, you prepared your {op-system-base-full} hosts, set all of the configuration values your cluster needed, and then ran an Ansible playbook to install and set up your cluster.
@@ -53,14 +53,14 @@ In {product-title} {product-version}, you use the OpenShift installation program
 
 For more information, see xref:../architecture/architecture-installation.adoc#installation-process_architecture-installation[Installation process].
 
-[discrete]
+
 === Infrastructure options
 
 In {product-title} 3.11, you installed your cluster on infrastructure that you prepared and maintained. In addition to providing your own infrastructure, {product-title} 4 offers an option to deploy a cluster on infrastructure that the {product-title} installation program provisions and the cluster maintains.
 
 For more information, see xref:../architecture/architecture-installation.adoc#installation-overview_architecture-installation[OpenShift Container Platform installation overview].
 
-[discrete]
+
 === Upgrading your cluster
 
 In {product-title} 3.11, you upgraded your cluster by running Ansible playbooks. In {product-title} {product-version}, the cluster manages its own updates, including updates to {op-system-first} on cluster nodes. You can easily upgrade your cluster by using the web console or by using the `oc adm upgrade` command from the OpenShift CLI and the Operators will automatically upgrade themselves. If your {product-title} {product-version} cluster has {op-system-base} worker machines, then you will still need to run an Ansible playbook to upgrade those worker machines.
@@ -77,28 +77,28 @@ Review the changes and other considerations that might affect your transition fr
 
 Review the following storage changes to consider when transitioning from {product-title} 3.11 to {product-title} {product-version}.
 
-[discrete]
+
 ==== Local volume persistent storage
 
 Local storage is only supported by using the Local Storage Operator in {product-title} {product-version}. It is not supported to use the local provisioner method from {product-title} 3.11.
 
 For more information, see xref:../storage/persistent_storage_local/persistent-storage-local.adoc#persistent-storage-using-local-volume[Persistent storage using local volumes].
 
-[discrete]
+
 ==== FlexVolume persistent storage
 
 The FlexVolume plugin location changed from {product-title} 3.11. The new location in {product-title} {product-version} is `/etc/kubernetes/kubelet-plugins/volume/exec`. Attachable FlexVolume plugins are no longer supported.
 
 For more information, see xref:../storage/persistent_storage/persistent-storage-flexvolume.adoc#persistent-storage-using-flexvolume[Persistent storage using FlexVolume].
 
-[discrete]
+
 ==== Container Storage Interface (CSI) persistent storage
 
 Persistent storage using the Container Storage Interface (CSI) was link:https://access.redhat.com/support/offerings/techpreview[Technology Preview] in {product-title} 3.11. {product-title} {product-version} ships with xref:../storage/container_storage_interface/persistent-storage-csi.adoc#csi-drivers-supported_persistent-storage-csi[several CSI drivers]. You can also install your own driver.
 
 For more information, see xref:../storage/container_storage_interface/persistent-storage-csi.adoc#persistent-storage-using-csi[Persistent storage using the Container Storage Interface (CSI)].
 
-[discrete]
+
 ==== Red Hat OpenShift Data Foundation
 
 OpenShift Container Storage 3, which is available for use with {product-title} 3.11, uses Red Hat Gluster Storage as the backing storage.
@@ -107,7 +107,7 @@ OpenShift Container Storage 3, which is available for use with {product-title} 3
 
 For more information, see xref:../storage/persistent_storage/persistent-storage-ocs.adoc#red-hat-openshift-data-foundation[Persistent storage using Red Hat OpenShift Data Foundation] and the link:https://access.redhat.com/articles/4731161[interoperability matrix] article.
 
-[discrete]
+
 ==== Unsupported persistent storage options
 
 Support for the following persistent storage options from {product-title} 3.11 has changed in {product-title} {product-version}:
@@ -120,7 +120,7 @@ If you used one of these in {product-title} 3.11, you must choose a different pe
 
 For more information, see xref:../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage].
 
-[discrete]
+
 ==== Migration of in-tree volumes to CSI drivers
 
 {product-title} 4 is migrating in-tree volume plugins to their Container Storage Interface (CSI) counterparts. In {product-title} {product-version}, CSI drivers are the new default for the following in-tree volume types:
@@ -146,7 +146,7 @@ For more information, see xref:../storage/container_storage_interface/persistent
 
 Review the following networking changes to consider when transitioning from {product-title} 3.11 to {product-title} {product-version}.
 
-[discrete]
+
 ==== Network isolation mode
 
 The default network isolation mode for {product-title} 3.11 was `ovs-subnet`, though users frequently switched to use `ovn-multitenant`. The default network isolation mode for {product-title} {product-version} is controlled by a network policy.
@@ -155,7 +155,7 @@ If your {product-title} 3.11 cluster used the `ovs-subnet` or `ovs-multitenant`
 
 For more information, see xref:../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[About network policy].
 
-[discrete]
+
 ==== OVN-Kubernetes as the default networking plugin in Red Hat OpenShift Networking
 
 In {product-title} 3.11, OpenShift SDN was the default networking plugin in Red Hat OpenShift Networking. In {product-title} {product-version}, OVN-Kubernetes is now the default networking plugin.
@@ -184,17 +184,17 @@ You should install {product-title} 4 with the OVN-Kubernetes network plugin beca
 
 Review the following logging changes to consider when transitioning from {product-title} 3.11 to {product-title} {product-version}.
 
-[discrete]
+
 ==== Deploying OpenShift Logging
 
 {product-title} 4 provides a simple deployment mechanism for OpenShift Logging, by using a Cluster Logging custom resource.
 
-[discrete]
+
 ==== Aggregated logging data
 
 You cannot transition your aggregate logging data from {product-title} 3.11 into your new {product-title} 4 cluster.
 
-[discrete]
+
 ==== Unsupported logging configurations
 
 Some logging configurations that were available in {product-title} 3.11 are no longer supported in {product-title} {product-version}.
@@ -204,14 +204,14 @@ Some logging configurations that were available in {product-title} 3.11 are no l
 
 Review the following security changes to consider when transitioning from {product-title} 3.11 to {product-title} {product-version}.
 
-[discrete]
+
 ==== Unauthenticated access to discovery endpoints
 
 In {product-title} 3.11, an unauthenticated user could access the discovery endpoints (for example, [x-]`/api/*` and [x-]`/apis/*`). For security reasons, unauthenticated access to the discovery endpoints is no longer allowed in {product-title} {product-version}. If you do need to allow unauthenticated access, you can configure the RBAC settings as necessary; however, be sure to consider the security implications as this can expose internal cluster components to the external network.
 
 // TODO: Anything to xref to, or additional details?
 
-[discrete]
+
 ==== Identity providers
 
 Configuration for identity providers has changed for {product-title} 4, including the following notable changes:
@@ -221,12 +221,12 @@ Configuration for identity providers has changed for {product-title} 4, includin
 
 For more information, see xref:../authentication/understanding-identity-provider.adoc#understanding-identity-provider[Understanding identity provider configuration].
 
-[discrete]
+
 ==== OAuth token storage format
 
 Newly created OAuth HTTP bearer tokens no longer match the names of their OAuth access token objects. The object names are now a hash of the bearer token and are no longer sensitive. This reduces the risk of leaking sensitive information.
 
-[discrete]
+
 ==== Default security context constraints
 
 The `restricted` security context constraints (SCC) in {product-title} 4 can no longer be accessed by any authenticated user as the `restricted` SCC in {product-title} 3.11. The broad authenticated access is now granted to the `restricted-v2` SCC, which is more restrictive than the old `restricted` SCC. The `restricted` SCC still exists; users that want to use it must be specifically given permissions to do it.
@@ -238,7 +238,7 @@ For more information, see xref:../authentication/managing-security-context-const
 
 Review the following monitoring changes when transitioning from {product-title} 3.11 to {product-title} {product-version}. You cannot migrate Hawkular configurations and metrics to Prometheus.
 
-[discrete]
+
 ==== Alert for monitoring infrastructure availability
 
 The default alert that triggers to ensure the availability of the monitoring structure was called `DeadMansSwitch` in {product-title} 3.11. This was renamed to `Watchdog` in {product-title} 4. If you had PagerDuty integration set up with this alert in {product-title} 3.11, you must set up the PagerDuty integration for the `Watchdog` alert in {product-title} 4.

migrating_from_ocp_3_to_4/troubleshooting-3-4.adoc

@@ -16,7 +16,7 @@ For known issues, see the xref:../migration_toolkit_for_containers/release_notes
 
 include::modules/migration-mtc-workflow.adoc[leveloffset=+1]
 
-[discrete]
+
 include::modules/migration-about-mtc-custom-resources.adoc[leveloffset=+2]
 
 include::modules/migration-mtc-cr-manifests.adoc[leveloffset=+1]
@@ -59,7 +59,7 @@ include::modules/migration-rolling-back-migration-manually.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 [id="additional-resources-uninstalling_{context}"]
-[discrete]
+
 === Additional resources
 
 * xref:../operators/admin/olm-deleting-operators-from-cluster.adoc#olm-deleting-operators-from-a-cluster-using-web-console_olm-deleting-operators-from-cluster[Deleting Operators from a cluster using the web console]