openshift · tedaveryredhat · Aug 6, 2026
diff --git a/applications/deployments/managing-deployment-processes.adoc b/applications/deployments/managing-deployment-processes.adoc
@@ -11,6 +11,7 @@ toc::[]
 
 include::snippets/deployment-config-deprecated.adoc[]
 
+[role="_abstract"]
 `DeploymentConfig` objects can be managed from the {product-title} web console's *Workloads* page or using the `oc` CLI. The following procedures show CLI usage unless otherwise stated.
 
 include::modules/deployments-starting-deployment.adoc[leveloffset=+2]
@@ -32,11 +33,12 @@ include::modules/deployments-setting-triggers.adoc[leveloffset=+3]
 include::modules/deployments-setting-resources.adoc[leveloffset=+2]
 
 // When the Nodes book is added to ROSA/OSD, check if this link is valid.
+
 ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 [role="_additional-resources"]
 .Additional resources
-
-* For more information about resource limits and requests, see xref:../../nodes/clusters/nodes-cluster-resource-configure.adoc#nodes-cluster-resource-configure-about_nodes-cluster-resource-configure[Understanding managing application memory].
+* xref:../../nodes/clusters/nodes-cluster-resource-configure.adoc#nodes-cluster-resource-configure-about_nodes-cluster-resource-configure[Understanding managing application memory]
+//in _<Configuring cluster memory to meet container memory and risk requirements>_.
 endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
 
 include::modules/deployments-scaling-manually.adoc[leveloffset=+2]

diff --git a/modules/deployments-accessing-private-repos.adoc b/modules/deployments-accessing-private-repos.adoc
@@ -6,7 +6,8 @@
 [id="deployments-accessing-private-repos_{context}"]
 = Accessing private repositories from DeploymentConfig objects
 
-You can add a secret to your `DeploymentConfig` object so that it can access images from a private repository. This procedure shows the {product-title} web console method.
+[role="_abstract"]
+To pull container images from a private repository into a `DeploymentConfig` object in {product-title}, you can add a pull secret. Create the secret in the web console, then set it as the pull secret on the `DeploymentConfig` object.
 
 .Procedure
 

diff --git a/modules/deployments-assigning-pods-to-nodes.adoc b/modules/deployments-assigning-pods-to-nodes.adoc
@@ -6,8 +6,8 @@
 [id="deployments-assigning-pods-to-nodes_{context}"]
 = Assigning pods to specific nodes
 
-You can use node selectors in conjunction with labeled nodes to control pod
-placement.
+[role="_abstract"]
+To control which nodes run your application pods in {product-title}, you can set a node selector on a `Pod` configuration or pod template. Combine your selector with labels on nodes, including any default project selectors set by a cluster administrator.
 
 Cluster administrators can set the default node selector for a project in order
 to restrict pod placement to specific nodes. As a developer, you can set a node

diff --git a/modules/deployments-exec-cmd-in-container.adoc b/modules/deployments-exec-cmd-in-container.adoc
@@ -6,7 +6,8 @@
 [id="deployments-exe-cmd-in-container_{context}"]
 = Executing commands inside a container
 
-You can add a command to a container, which modifies the container's startup behavior by overruling the image's `ENTRYPOINT`. This is different from a lifecycle hook, which instead can be run once per deployment at a specified time.
+[role="_abstract"]
+To change how a container starts in a `DeploymentConfig` object in {product-title}, you can set a `command` and optional `args` in the pod template. These values override the image `ENTRYPOINT` and differ from lifecycle hooks, which run once per deployment at a specified time.
 
 .Procedure
 

diff --git a/modules/deployments-retrying-deployment.adoc b/modules/deployments-retrying-deployment.adoc
@@ -6,7 +6,8 @@
 [id="deployments-retrying-deployment_{context}"]
 = Retrying a deployment
 
-If the current revision of your `DeploymentConfig` object failed to deploy, you can restart the deployment process.
+[role="_abstract"]
+To restart a failed rollout of a `DeploymentConfig` object in {product-title}, you can retry the deployment. Use the `oc rollout retry` command to restart the same revision without creating a new deployment revision.
 
 .Procedure
 

diff --git a/modules/deployments-rolling-back.adoc b/modules/deployments-rolling-back.adoc
@@ -6,6 +6,7 @@
 [id="deployments-rolling-back_{context}"]
 = Rolling back a deployment
 
+[role="_abstract"]
 Rollbacks revert an application back to a previous revision and can be performed using the REST API, the CLI, or the web console.
 
 .Procedure

diff --git a/modules/deployments-running-pod-svc-acct.adoc b/modules/deployments-running-pod-svc-acct.adoc
@@ -6,7 +6,8 @@
 [id="deployments-running-pod-svc-acct_{context}"]
 = Running a pod with a different service account
 
-You can run a pod with a service account other than the default.
+[role="_abstract"]
+To run pods under a non-default identity in {product-title}, you can assign a different service account to a `DeploymentConfig` object. Edit the object and set the `serviceAccount` and `serviceAccountName` fields to the account you want to use.
 
 .Procedure
 

diff --git a/modules/deployments-scaling-manually.adoc b/modules/deployments-scaling-manually.adoc
@@ -6,7 +6,8 @@
 [id="deployments-scaling-manually_{context}"]
 = Scaling manually
 
-In addition to rollbacks, you can exercise fine-grained control over the number of replicas by manually scaling them.
+[role="_abstract"]
+To control how many pod replicas run for a `DeploymentConfig` object in {product-title}, you can scale manually. Use the `oc scale` command to set the desired number of replicas.
 
 [NOTE]
 ====

diff --git a/modules/deployments-setting-resources.adoc b/modules/deployments-setting-resources.adoc
@@ -6,6 +6,9 @@
 [id="deployments-setting-resources_{context}"]
 = Setting deployment resources
 
+[role="_abstract"]
+To limit CPU, memory, and ephemeral storage used by a deployment in {product-title}, you can set resource limits on the deployment strategy. Define limits in the `resources` section so deployer pods do not consume unbounded node capacity.
+
 A deployment is completed by a pod that consumes resources (memory, CPU, and ephemeral storage) on a node. By default, pods consume unbounded node resources. However, if a project specifies default container limits, then pods consume resources up to those limits.
 
 [NOTE]
@@ -31,13 +34,13 @@ spec:
   type: "Recreate"
   resources:
     limits:
-      cpu: "100m" <1>
-      memory: "256Mi" <2>
+      cpu: "100m"
+      memory: "256Mi"
       ephemeral-storage: "1Gi" <3>
 ----
-<1> `cpu` is in CPU units: `100m` represents 0.1 CPU units (100 * 1e-3).
-<2> `memory` is in bytes: `256Mi` represents 268435456 bytes (256 * 2 ^ 20).
-<3> `ephemeral-storage` is in bytes: `1Gi` represents 1073741824 bytes (2 ^ 30).
+* `spec.resources.limits.cpu` specifies the CPU units: `100m` represents 0.1 CPU units (100 * 1e-3).
+* `spec.resources.limits.memory` specifies the bytes for memory: `256Mi` represents 268435456 bytes (256 * 2 ^ 20).
+* `spec.resources.limits.ephemeral-storage` specifies the bytes for ephemeral-storage: `1Gi` represents 1073741824 bytes (2 ^ 30).
 +
 However, if a quota has been defined for your project, one of the following two items is required:
 +
@@ -55,12 +58,13 @@ spec:
 # ...
   type: "Recreate"
   resources:
-    requests: <1>
+    requests:
       cpu: "100m"
       memory: "256Mi"
       ephemeral-storage: "1Gi"
 ----
-<1> The `requests` object contains the list of resources that correspond to the list of resources in the quota.
++
+The `spec.resources.requests` object contains the list of resources that correspond to the list of resources in the quota.
 
 - A limit range defined in your project, where the defaults from the `LimitRange` object apply to pods created during the deployment process.
 --

diff --git a/modules/deployments-setting-triggers.adoc b/modules/deployments-setting-triggers.adoc
@@ -6,6 +6,9 @@
 [id="deployments-setting-triggers_{context}"]
 = Setting deployment triggers
 
+[role="_abstract"]
+To automatically start a new rollout when an image changes in {product-title}, you can set deployment triggers on a `DeploymentConfig` object. Use the `oc set triggers` command to configure an image change trigger for a container.
+
 .Procedure
 
 . You can set deployment triggers for a `DeploymentConfig` object using the `oc set triggers` command. For example, to set a image change trigger, use the following command:

diff --git a/modules/deployments-starting-deployment.adoc b/modules/deployments-starting-deployment.adoc
@@ -6,7 +6,8 @@
 [id="deployments-starting-a-deployment_{context}"]
 = Starting a deployment
 
-You can start a rollout to begin the deployment process of your application.
+[role="_abstract"]
+To begin a new rollout of your application in {product-title}, you can start a deployment from an existing `DeploymentConfig` object. Use the `oc rollout latest` command to create a new replication controller and run the deployment process.
 
 .Procedure
 

diff --git a/modules/deployments-triggers.adoc b/modules/deployments-triggers.adoc
@@ -6,7 +6,8 @@
 [id="deployments-triggers_{context}"]
 = Deployment triggers
 
-A `DeploymentConfig` object can contain triggers, which drive the creation of new deployment processes in response to events inside the cluster.
+[role="_abstract"]
+A deployment trigger on a `DeploymentConfig` object in {product-title} starts a new deployment process when cluster events occur. Use config change or image change triggers to roll out automatically, or leave triggers empty if you want to start deployments only manually.
 
 [WARNING]
 ====
@@ -55,15 +56,15 @@ spec:
   triggers:
     - type: "ImageChange"
       imageChangeParams:
-        automatic: true <1>
+        automatic: true
         from:
           kind: "ImageStreamTag"
           name: "origin-ruby-sample:latest"
           namespace: "myproject"
         containerNames:
           - "helloworld"
 ----
-<1> If the `imageChangeParams.automatic` field is set to `false`, the trigger is disabled.
+If the `triggers.imageChangeParams.automatic` field is set to `false`, the trigger is disabled.
 
 With the above example, when the `latest` tag value of the `origin-ruby-sample` image stream changes and the new image value differs from the current image specified in the `DeploymentConfig` object's `helloworld` container, a new replication controller is created using the new image for the `helloworld` container.
 

diff --git a/modules/deployments-viewing-deployment.adoc b/modules/deployments-viewing-deployment.adoc
@@ -6,7 +6,8 @@
 [id="deployments-viewing-a-deployment_{context}"]
 = Viewing a deployment
 
-You can view a deployment to get basic information about all the available revisions of your application.
+[role="_abstract"]
+To review the rollout history of your application in {product-title}, you can view a deployment. Use the `oc rollout history` and `oc describe` commands to inspect revisions of a `DeploymentConfig` object.
 
 .Procedure
 

diff --git a/modules/deployments-viewing-logs.adoc b/modules/deployments-viewing-logs.adoc
@@ -6,6 +6,9 @@
 [id="deployments-viewing-logs_{context}"]
 = Viewing deployment logs
 
+[role="_abstract"]
+To troubleshoot a rollout in {product-title}, you can view deployment logs for a `DeploymentConfig` object. Use the `oc logs` command to stream logs from the latest revision or from an older failed deployment process.
+
 .Procedure
 
 . To stream the logs of the latest revision for a given `DeploymentConfig` object: