Merge pull request #96978 from ShaunaDiaz/CP-414-OSDOCS-11585-3

ShaunaDiaz · web-flow · commit 873d406c0cf7 · 2025-08-01T13:08:37.000-04:00
CP-414-OSDOCS-11585-3: backports unused content removal MicroShift
diff --git a/_topic_maps/_topic_map_ms.yml b/_topic_maps/_topic_map_ms.yml
@@ -475,6 +475,8 @@ Topics:
   File: microshift-troubleshoot-backup-restore
 - Name: Troubleshoot the cluster
   File: microshift-troubleshoot-cluster
+- Name: Troubleshoot etcd
+  File: microshift-etcd-troubleshoot
 - Name: Troubleshoot updates
   File: microshift-troubleshoot-updates
 - Name: Checking audit logs
diff --git a/_unused_topics/microshift-man-config-ovs-bridge.adoc b/_unused_topics/microshift-man-config-ovs-bridge.adoc
diff --git a/_unused_topics/microshift-nodeport-unreachable-workaround.adoc b/_unused_topics/microshift-nodeport-unreachable-workaround.adoc
diff --git a/microshift_install/microshift-installing-troubleshooting.adoc b/microshift_install/microshift-installing-troubleshooting.adoc
@@ -15,4 +15,4 @@ include::modules/microshift-gathering-sos-report.adoc[leveloffset=+1]
 == Additional resources
 * xref:../microshift_support/microshift-sos-report.adoc#microshift-sos-report[About {microshift-short} sos reports]
 
-* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/getting_the_most_from_your_support_experience/generating-an-sos-report-for-technical-support_getting-the-most-from-your-support-experience[Generating an sos report for technical support]
+* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/getting_the_most_from_your_support_experience/generating-an-sos-report-for-technical-support_getting-the-most-from-your-support-experience[Generating an sos report for technical support]
diff --git a/microshift_running_apps/microshift-embedded-apps-on-rhel-edge.adoc b/microshift_running_apps/microshift-embedded-apps-on-rhel-edge.adoc
@@ -52,5 +52,3 @@ If you have an application that includes more than a few files, you can embed th
 * link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/{op-system-version-major}/html-single/composing_installing_and_managing_rhel_for_edge_images/index#composing-a-rhel-for-edge-image-using-image-builder-command-line_composing-installing-managing-rhel-for-edge-images[Composing a RHEL for Edge image using image builder command-line]
 
 * link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/{op-system-version-major}/html-single/composing_installing_and_managing_rhel_for_edge_images/index#edge-image-builder-system-requirements_setting-up-image-builder[Image Builder system requirements]
-
-//* link:https://www.redhat.com/sysadmin/create-rpm-package[How to create a Linux RPM package]
diff --git a/microshift_storage/index.adoc b/microshift_storage/index.adoc
@@ -26,9 +26,4 @@ Stateful applications deployed in containers require persistent storage. {micros
 [id="microshift-dynamic-provisioning-overview"]
 === Dynamic storage provisioning
 
-Using dynamic provisioning allows you to create storage volumes on-demand, eliminating the need for pre-provisioned storage. For more information about how dynamic provisioning works in {product-title}, read xref:../microshift_storage/microshift-storage-plugin-overview.adoc#microshift-storage-plugin-overview[Dynamic provisioning].
-
-//[id="microshift-container-storage-interface"]
-//== Container Storage Interface (CSI)
-
-//CSI is an API specification for the management of container storage across different container orchestration (CO) systems. You can manage the storage volumes within the container native environments, without having specific knowledge of the underlying storage infrastructure. With the CSI, storage works uniformly across different container orchestration systems, regardless of the storage vendors you are using. For more information about CSI, read ../microshift_storage/container_storage_interface_microshift/microshift-persistent-storage-csi.adoc#persistent-storage-csi-microshift[Using Container Storage Interface (CSI) for MicroShift].
+Using dynamic provisioning allows you to create storage volumes on-demand, eliminating the need for pre-provisioned storage. For more information about how dynamic provisioning works in {product-title}, read xref:../microshift_storage/microshift-storage-plugin-overview.adoc#[Dynamic provisioning using the LVMS plugin].
diff --git a/microshift_storage/volume-snapshots-microshift.adoc b/microshift_storage/volume-snapshots-microshift.adoc
@@ -93,6 +93,4 @@ include::modules/microshift-storage-volume-cloning.adoc[leveloffset=+1]
 
 * link:https://docs.openshift.com/container-platform/{ocp-version}/storage/container_storage_interface/persistent-storage-csi-cloning.html[CSI volume cloning]
 
-* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/storage/configuring-persistent-storage#lvms-creating-volume-clones-in-single-node-openshift_logical-volume-manager-storage[LVMS volume cloning for Single-Node OpenShift]
-
 * To configure the host to enable cloning, see xref:../microshift_storage/volume-snapshots-microshift.adoc#microshift-lvm-thin-volumes_volume-snapshots-microshift[About LVM thin volumes]
diff --git a/microshift_support/microshift-etcd.adoc b/microshift_support/microshift-etcd.adoc
@@ -6,8 +6,7 @@ include::_attributes/attributes-microshift.adoc[]
 
 toc::[]
 
-[role="_abstract"]
-The etcd service is delivered as part of the {product-title} RPM. The etcd service is run as a separate process and the lifecycle is managed automatically by {product-title}.
+The {product-title} RPM includes the etcd service. The etcd service runs as a separate process. {microshift-short} automatically manages the etcd lifecycle.
 
 include::modules/microshift-observe-debug-etcd-server.adoc[leveloffset=+1]
 
diff --git a/microshift_support/microshift-sos-report.adoc b/microshift_support/microshift-sos-report.adoc
@@ -6,7 +6,6 @@ include::_attributes/attributes-microshift.adoc[]
 
 toc::[]
 
-[role="_abstract"]
 You can use the `sos` tool to collect troubleshooting information about a host. The `sos report` command generates a detailed report that shows all of the enabled plugins and data from the different components and applications in a system.
 
 include::modules/microshift-about-sos-reports.adoc[leveloffset=+1]
diff --git a/microshift_troubleshooting/microshift-audit-logs.adoc b/microshift_troubleshooting/microshift-audit-logs.adoc
@@ -8,4 +8,4 @@ toc::[]
 
 You can use audit logs to identify pod security violations.
 
-include::modules/microshift-viewing-audit-logs.adoc[leveloffset=+1]
+include::modules/microshift-viewing-audit-logs.adoc[leveloffset=+1]
diff --git a/microshift_troubleshooting/microshift-etcd-troubleshoot.adoc b/microshift_troubleshooting/microshift-etcd-troubleshoot.adoc
@@ -0,0 +1,11 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="microshift-etcd-troubleshoot"]
+= Troubleshoot etcd
+include::_attributes/attributes-microshift.adoc[]
+:context: microshift-etcd-troubleshoot
+
+toc::[]
+
+To troubleshoot etcd and improve performance, configure the memory allowance for the service.
+
+include::modules/microshift-config-etcd.adoc[leveloffset=+1]
diff --git a/modules/storage-persistent-storage-pvc.adoc b/modules/storage-persistent-storage-pvc.adoc
@@ -1,14 +1,15 @@
+ change
+@@ -1,115 +0,0 @@
 // Module included in the following assemblies:
 //
 // * storage/understanding-persistent-storage.adoc
 //* microshift_storage/understanding-persistent-storage-microshift.adoc
 
-
+:_mod-docs-content-type: CONCEPT
 [id="persistent-volume-claims_{context}"]
-= Persistent volume claims
+== Persistent volume claims
 
-Each `PersistentVolumeClaim` object contains a `spec` and `status`, which
-is the specification and status of the persistent volume claim (PVC), for example:
+Each `PersistentVolumeClaim` object contains `spec` and `status` fields, which are the specification and status of the persistent volume claim (PVC), for example:
 
 .`PersistentVolumeClaim` object definition example
 [source,yaml]
@@ -28,29 +29,19 @@ status:
   ...
 ----
 <1> Name of the PVC.
-<2> The access mode, defining the read-write and mount permissions.
+<2> The access mode, defining the read/write and mount permissions.
 <3> The amount of storage available to the PVC.
 <4> Name of the `StorageClass` required by the claim.
 
 [id="pvc-storage-class_{context}"]
 == Storage classes
 
-Claims can optionally request a specific storage class by specifying the
-storage class's name in the `storageClassName` attribute. Only PVs of the
-requested class, ones with the same `storageClassName` as the PVC, can be
-bound to the PVC. The cluster administrator can configure dynamic
-provisioners to service one or more storage classes. The cluster
-administrator can create a PV on demand that matches the specifications
-in the PVC.
+Claims can optionally request a specific storage class by specifying the storage class's name in the `storageClassName` attribute. Only PVs of the requested class, ones with the same `storageClassName` as the PVC, can be bound to the PVC. The cluster administrator can configure dynamic provisioners to service one or more storage classes. The cluster administrator can create a PV on-demand that matches the specifications in the PVC.
 
 ifndef::microshift,openshift-rosa[]
 [IMPORTANT]
 ====
-The Cluster Storage Operator might install a default storage class depending
-on the platform in use. This storage class is owned and controlled by the
-Operator. It cannot be deleted or modified beyond defining annotations
-and labels. If different behavior is desired, you must define a custom
-storage class.
+The Cluster Storage Operator might install a default storage class depending on the platform in use. This storage class is owned and controlled by the Operator. It cannot be deleted or modified beyond defining annotations and labels. If different behavior is desired, you must define a custom storage class.
 ====
 endif::microshift,openshift-rosa[]
 ifdef::openshift-rosa[]
@@ -60,10 +51,7 @@ The Cluster Storage Operator installs a default storage class. This storage clas
 ====
 endif::openshift-rosa[]
 
-The cluster administrator can also set a default storage class for all PVCs.
-When a default storage class is configured, the PVC must explicitly ask for
-`StorageClass` or `storageClassName` annotations set to `""` to be bound
-to a PV without a storage class.
+The cluster administrator can also set a default storage class for all PVCs. When a default storage class is configured, the PVC must explicitly ask for `StorageClass` or `storageClassName` annotations set to `""` to be bound to a PV without a storage class.
 
 [NOTE]
 ====
@@ -73,23 +61,17 @@ If more than one storage class is marked as default, a PVC can only be created i
 [id="pvc-access-modes_{context}"]
 == Access modes
 
-Claims use the same conventions as volumes when requesting storage with
-specific access modes.
+Claims use the same conventions as volumes when requesting storage with specific access modes.
 
 [id="pvc-resources_{context}"]
 == Resources
 
-Claims, such as pods, can request specific quantities of a resource. In
-this case, the request is for storage. The same resource model applies to
-volumes and claims.
+Claims, such as pods, can request specific quantities of a resource. In this case, the request is for storage. The same resource model applies to volumes and claims.
 
 [id="pvc-claims-as-volumes_{context}"]
 == Claims as volumes
 
-Pods access storage by using the claim as a volume. Claims must exist in the
-same namespace as the pod using the claim. The cluster finds the claim
-in the pod's namespace and uses it to get the `PersistentVolume` backing
-the claim. The volume is mounted to the host and into the pod, for example:
+Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the pod using the claim. The cluster finds the claim in the pod's namespace and uses it to get the `PersistentVolume` backing the claim. The volume is mounted to the host and into the pod, for example:
 
 .Mount volume to the host and into the pod example
 [source,yaml]
@@ -112,4 +94,4 @@ spec:
 ----
 <1> Path to mount the volume inside the pod.
 <2> Name of the volume to mount. Do not mount to the container root, `/`, or any path that is the same in the host and the container. This can corrupt your host system if the container is sufficiently privileged, such as the host `/dev/pts` files. It is safe to mount the host by using `/host`.
-<3> Name of the PVC, that exists in the same namespace, to use.
+<3> Name of the PVC, that exists in the same namespace, to use.
diff --git a/snippets/microshift-tech-preview-snip.adoc b/snippets/microshift-tech-preview-snip.adoc
diff --git a/snippets/microshift-upload-cont2-mirror-script.adoc b/snippets/microshift-upload-cont2-mirror-script.adoc
@@ -24,4 +24,5 @@ while read -r src_manifest ; do
 
 done < <(find . -type f -name manifest.json -printf '%P\n')
 popd >/dev/null
-----
+----
+//used 4.14-4.16 only

Original file line number	Diff line number	Diff line change
`@@ -8,4 +8,4 @@ toc::[]`
`8`	`8`
`9`	`9`	`You can use audit logs to identify pod security violations.`
`10`	`10`
`11`		`-include::modules/microshift-viewing-audit-logs.adoc[leveloffset=+1]`
	`11`	`+include::modules/microshift-viewing-audit-logs.adoc[leveloffset=+1]`