Fix typos and HTML errors in rolling-deploy; fix RESTRICTED state description in stacks [ai-assisted]

anita-flegg · anita-flegg · commit d1fb93704874 · 2026-03-06T11:03:45.000-08:00
Made-with: Cursor
diff --git a/deploy-apps/rolling-deploy.html.md.erb b/deploy-apps/rolling-deploy.html.md.erb
@@ -31,7 +31,7 @@ Or for canary deployments:
 Cloud Foundry provides two different strategies for deployments:
 
 * A **Rolling** deployment brings up one or more web processes for the new app version, with the number set by `max-in-flight`, which defaults to 1. After those instances report as healthy and routable, it brings down the same number of instances of the old version. The deployment repeats this process to replace all web process instances, and then updates all old non-web processes.
-* A **Canary** deployment brings up one or more web processes for the new app version, defaulting to one. It then pauses to let app operators or developers evaluate the health of a new version instances. App operators can then choose to either `cancel` or `continue` the deployment. When the deployment is continued, the canary deployment proceeds in the same way as a rolling deployment.
+* A **Canary** deployment brings up one or more web processes for the new app version, defaulting to one. It then pauses to let app operators or developers evaluate the health of new version instances. App operators can then choose to either `cancel` or `continue` the deployment. When the deployment is continued, the canary deployment proceeds in the same way as a rolling deployment.
   * To gradually increase instance counts and check app health in multiple steps, the latest cf CLI v8 supports an `--instance-steps` option that sets a series of increasing instance counts.
 
 Each rolling or canary deployment increments the `revision` count for the new app deployment, as listed by the `cf revisions` command described in [App Revisions Overview](../revisions.html).
@@ -78,12 +78,12 @@ background, updating deployments as follows:
         * If you run `cf app` on your app at this point, you see multiple `web` processes.
     2. Sets the deployment to `PAUSED`.
 
-1. After validating that the canary instance is running as expected, execute the command `cf continue-deployment APP-NAME`:
+3. After validating that the canary instance is running as expected, execute the command `cf continue-deployment APP-NAME`:
     * Changes the deployment reason to `DEPLOYING` and resumes following the same process as a rolling deployment.
 
-2. After the command changes the status of the deployment, the `cc_deployment_updater` BOSH job runs in the
+4. After the command changes the status of the deployment, the `cc_deployment_updater` BOSH job runs in the
 background, updating deployments as follows:
-    1. Adds MaxInFlight number of instances (**by default it is 1**) of the new web process and removes MaxInFlight number of instance from the old web process. This step repeats until the new web process reaches the required number of instances.
+    1. Adds MaxInFlight number of instances (**by default it is 1**) of the new web process and removes MaxInFlight number of instances from the old web process. This step repeats until the new web process reaches the required number of instances.
         <p class="note important">
         This happens only if all instances of the new web process are running.</p>
     2. Removes the old web process. The new web process now fully replaces the old web process.
@@ -406,7 +406,7 @@ droplet GUID from the output.
       -H "Content-type: application/json" \
       -d '{
         "package": {
-          "guid": PACKAGE-GUID"
+          "guid": "PACKAGE-GUID"
         }
       }'
     ```
@@ -464,7 +464,7 @@ To stop the deployment of an app that you pushed:
 * **For CAPI V3, run:**
 
     ```
-    cf curl /v3/deployments/DEPLOYMENT-GUID/actions/cancel" -X POST
+    cf curl /v3/deployments/DEPLOYMENT-GUID/actions/cancel -X POST
     ```
 
     Where `DEPLOYMENT-GUID` is the GUID of the deployment that you recorded after following the
@@ -496,7 +496,7 @@ To finish a canary deployment after the deployment has paused and the canary ins
 * **For CAPI V3, run:**
 
     ```
-    cf curl /v3/deployments/DEPLOYMENT-GUID/actions/continue" -X POST
+    cf curl /v3/deployments/DEPLOYMENT-GUID/actions/continue -X POST
     ```
     Where `DEPLOYMENT-GUID` is the GUID of the deployment that you recorded after following the
     CAPI procedure in [Deploy an app](#deploy).
@@ -530,7 +530,7 @@ To restart your app without downtime, run the appropriate command as shown here.
     Where:
     <ul>
       <li><code>APP-NAME</code> is the name of the app.</li>
-      <li><code>MAX_IN_FLIGHT</code> specifies the maximum number of new instances to restart simultaneous until the deployment is complete. Optional and defaults to 1.</li>
+      <li><code>MAX_IN_FLIGHT</code> specifies the maximum number of new instances to restart simultaneously until the deployment is complete. Optional and defaults to 1.</li>
       <li><code>STRATEGY</code> is the strategy you would like to use for the deployment. Valid strategies are <code>rolling</code> and <code>canary</code>.</li>
     </ul>
 
@@ -561,7 +561,7 @@ To restart your app without downtime, run the appropriate command as shown here.
     Where:
       <ul>
         <li><code>DROPLET-GUID</code> and <code>APP-GUID</code> are the GUIDs that you recorded in earlier steps.</li>
-        <li><code>MAX_IN_FLIGH</code> is an integer that specifies the maximum number of new instances to start up simultaneous until the deployment is complete. Optional and defaults to 1.</li>
+        <li><code>MAX_IN_FLIGHT</code> is an integer that specifies the maximum number of new instances to start up simultaneously until the deployment is complete. Optional and defaults to 1.</li>
         <li><code>STRATEGY</code> is the strategy you would like to use for the deployment. Valid strategies are <code>rolling</code> and <code>canary</code>.</li>
       </ul>
 
diff --git a/deploy-apps/stacks.html.md.erb b/deploy-apps/stacks.html.md.erb
@@ -39,7 +39,7 @@ Operators can assign a lifecycle state to each stack. The state affects what ope
 |--------------|------------------------------|
 | `ACTIVE`     | The stack is fully available. You can push new apps and restage existing apps. |
 | `DEPRECATED` | The stack is still usable, but a warning is shown during `cf push` and `cf restage`. Plan to migrate your apps soon. |
-| `RESTRICTED` | You cannot push new apps using this stack. Existing apps can still be restarted and scaled. |
+| `RESTRICTED` | You cannot push new apps using this stack. Existing apps can still be restaged, restarted, and scaled. |
 | `DISABLED`   | You cannot stage or restage any app using this stack. Existing apps continue to run and can be restarted and scaled. |
 
 When a stack has a state other than `ACTIVE`, operators typically provide a **reason** message with migration guidance. This reason is shown in `cf stacks`, `cf stack STACK_NAME`, and in any warning or error messages during `cf push` or `cf restage`.
