Merge pull request #302119 from tfitzmac/0701edit8

denrea · web-flow · commit e9f5ce45c192 · 2025-07-16T09:28:37.000-07:00
copy edit
diff --git a/articles/cyclecloud/service-policy.md b/articles/cyclecloud/service-policy.md
@@ -4,55 +4,55 @@ description: Complete service policy for Azure CycleCloud. See release types, re
 services: azure cyclecloud
 author: KimliW
 ms.topic: conceptual
-ms.date: 06/13/2025
+ms.date: 07/01/2025
 ms.author: adjohnso
 ---
 
-# Azure CycleCloud Service Policy
+# Azure CycleCloud service policy
 
-This article describes the servicing policy for Azure CycleCloud, and what you must do to keep your system in a supported state.
+This article describes the servicing policy for Azure CycleCloud and what you need to do to keep your system in a supported state.
 
-## Lifecycle Policy
+## Lifecycle policy
 
 Azure CycleCloud follows Microsoft's [Modern Lifecycle Policy](https://support.microsoft.com/help/30881/modern-lifecycle-policy).
 
-## Release Types
+## Release types
 
-Microsoft is responsible for the end-to-end servicing lifecycle for the Azure CycleCloud software release and update packages, which can be downloaded directly from Microsoft. We recommend Azure CycleCloud Operators set maintenance windows when installing releases. Releases update your Azure CycleCloud installation's version.
+Microsoft manages the end-to-end servicing lifecycle for the Azure CycleCloud software release and update packages. You can download these packages directly from Microsoft. We recommend that Azure CycleCloud operators set maintenance windows when installing releases. Each release updates your Azure CycleCloud installation's version.
 
-There are three types of Azure CycleCloud release: major, minor, and hotfix.
+There are three types of Azure CycleCloud releases: major, minor, and hotfix.
 
-* **Major Release**: These packages include the latest Azure CycleCloud features and functionality. Although we attempt to minimize any breaking changes between major versions, we do not guarantee backwards compatibility between major releases. We will make efforts to call out any relevant warnings or details for upgrading.
-* **Minor Update**: These packages can include the latest Azure CycleCloud security updates, bug fixes, and feature updates. We guarantee backwards compatibility within all the minor releases for a given major release.
-* **Hotfix**: Occasionally, Microsoft provides Azure CycleCloud hotfixes that address a specific issue or issues that are often preventative or time-sensitive. A separate hotfix may be provided for each supported version of Azure CycleCloud as appropriate. Each fix for a specific iteration is cumulative and includes the previous updates for that same version.
+* **Major release**: These packages include the latest Azure CycleCloud features and functionality. Although we attempt to minimize any breaking changes between major versions, we don't guarantee backwards compatibility between major releases. We make efforts to call out any relevant warnings or details for upgrading.
+* **Minor update**: These packages include the latest Azure CycleCloud security updates, bug fixes, and feature updates. We guarantee backwards compatibility within all the minor releases for a given major release.
+* **Hotfix**: Occasionally, Microsoft provides Azure CycleCloud hotfixes that address a specific issue or issues that are often preventative or time-sensitive. Microsoft might provide a separate hotfix for each supported version of Azure CycleCloud. Each fix for a specific version is cumulative and includes previous updates for that same version.
 
 For more information about a specific release, see the [product documentation](/azure/cyclecloud/release-notes).
 
-## Azure CycleCloud Release Cadence
+## Azure CycleCloud release cadence
 
-Microsoft expects to release Azure CycleCloud updates on a monthly cadence. However, it's possible to have multiple, or no update releases in a month.
+Microsoft plans to release Azure CycleCloud updates every month. However, some months might have multiple updates or no updates.
 
-For information about a specific update see the release notes for that update in our [product documentation](/azure/cyclecloud/release-notes).
+For information about a specific update, see the release notes for that update in our [product documentation](/azure/cyclecloud/release-notes).
 
-## Supported Azure CycleCloud Versions
+## Supported Azure CycleCloud versions
 
-To continue to receive support, you must keep your Azure CycleCloud deployment current to either the previous or latest major releases, running any minor update version for either major release.
+To continue receiving support, keep your Azure CycleCloud deployment current with either the previous or latest major releases. You can run any minor update version for either major release.
 
-If your Azure CycleCloud installation is behind by more than two major release updates, it's considered out of compliance and must be updated to at least the minimum supported version.
+If your Azure CycleCloud installation is behind by more than two major release updates, it's considered out of compliance. You must update it to at least the minimum supported version.
 
-For example, if the previous and current major releases are versions 6 and 7, and the three most recent update versions are:
+For example, if the previous and current major releases are versions 6 and 7, the three most recent update versions are:
 
 * Version 6:  6.8.0, 6.7.0, 6.6.0
 * Version 7:  7.2.0, 7.1.1, 7.0.0
 
-In this example, all versions listed above would be supported, but 5.x.x - and all prior versions - would be out of support. Additionally, when version 8.x.x is released, version 6.x would transition to legacy/unsupported.
+In this example, all versions listed earlier are supported, but versions 5.x.x and earlier versions are out of support. When version 8.x.x is released, version 6.x.x transitions to legacy unsupported.
 
-Azure CycleCloud software update packages are cumulative. If you decide to defer one or more updates, you may install the latest update package to become compliant.
+Azure CycleCloud software update packages are cumulative. If you defer one or more updates, you can install the latest update package to become compliant.
 
-## Keeping Your System Supported
+## Keep your system supported
 
-See product documentation to learn how to upgrade running deployments to a supported version: [Upgrade Azure CycleCloud](~/articles/cyclecloud/how-to/upgrade-and-migrate.md).
+To learn how to upgrade running deployments to a supported version, see the product documentation: [Upgrade Azure CycleCloud](~/articles/cyclecloud/how-to/upgrade-and-migrate.md).
 
-## Get Support
+## Get support
 
 Azure CycleCloud follows the same support process as Azure. Enterprise customers can follow the process described in [How to Create an Azure Support Request](/azure/azure-supportability/how-to-create-azure-support-request). For more information, see the [Azure Support FAQs](https://azure.microsoft.com/support/faq/).
diff --git a/articles/cyclecloud/slurm-3.md b/articles/cyclecloud/slurm-3.md
@@ -2,43 +2,43 @@
 title: Slurm Scheduler Integration version 3.0
 description: New CycleCloud Slurm 3.0+ functionality.
 author: anhoward
-ms.date: 06/13/2025
+ms.date: 07/01/2025
 ms.author: anhoward
 ---
 
 # CycleCloud Slurm 3.0
 
-Slurm scheduler support was rewritten as part of the CycleCloud 8.4.0 release. Key features include:
+We rewrote the Slurm scheduler support as part of the CycleCloud 8.4.0 release. Key features include:
 
-* Support for dynamic nodes, and dynamic partitions via dynamic nodearays, supporting both single and multiple virtual machine (VM) sizes
-* New Slurm versions 23.02 and 22.05.8
-* Cost reporting via `azslurm` CLI
-* `azslurm` cli based autoscaler
-* Ubuntu 20 support
-* Removed need for topology plugin, and therefore also any submit plugin
+* Support for dynamic nodes and dynamic partitions through dynamic node arrays. This feature supports both single and multiple virtual machine (VM) sizes.
+* New Slurm versions 23.02 and 22.05.8.
+* Cost reporting through the `azslurm` CLI.
+* `azslurm` CLI-based autoscaler.
+* Ubuntu 20 support.
+* Removed need for topology plugin and any associated submit plugin.
 
-## Slurm Clusters in CycleCloud versions < 8.4.0
+## Slurm Clusters in CycleCloud versions earlier than 8.4.0
 
 For more information, see [Transitioning from 2.7 to 3.0](#transitioning-from-27-to-30).
 
-### Making Cluster Changes
+### Making cluster changes
 
-The Slurm cluster deployed in CycleCloud contains a cli called `azslurm` to facilitate making changes to the cluster. After making any changes to the cluster, run the following command as root on the Slurm scheduler node to rebuild the `azure.conf` and update the nodes in the cluster:
+The Slurm cluster that you deploy in CycleCloud includes a CLI called `azslurm` to help you make changes to the cluster. After making any changes to the cluster, run the following command as root on the Slurm scheduler node to rebuild the `azure.conf` and update the nodes in the cluster:
 
 ```bash
       $ sudo -i
       # azslurm scale
 ```
 
-The command creates the partitions with the correct number of nodes, the proper `gres.conf` and restart the `slurmctld`.
+The command creates the partitions with the correct number of nodes, sets up the proper `gres.conf`, and restarts the `slurmctld`.
 
-### No longer precreating execute nodes
+### Nodes aren't precreated anymore
 
-Starting CycleCloud version 3.0.0 Slurm project, the nodes aren't precreating. Nodes are created when `azslurm resume` is invoked, or by manually creating them in CycleCloud using CLI.
+Starting with CycleCloud version 3.0.0 Slurm project, the nodes aren't precreated. You create nodes when you invoke `azslurm resume` or when you manually create them in CycleCloud using the CLI.
 
 ### Creating extra partitions
 
-The default template that ships with Azure CycleCloud has three partitions (`hpc`, `htc` and `dynamic`), and you can define custom nodearrays that map directly to Slurm partitions. For example, to create a GPU partition, add the following section to your cluster template:
+The default template that ships with Azure CycleCloud has three partitions (`hpc`, `htc`, and `dynamic`), and you can define custom node arrays that map directly to Slurm partitions. For example, to create a GPU partition, add the following section to your cluster template:
 
 ```ini
    [[nodearray gpu]]
@@ -58,9 +58,9 @@ The default template that ships with Azure CycleCloud has three partitions (`hpc
       AssociatePublicIpAddress = $ExecuteNodesPublic
 ```
 
-### Dynamic Partitions
+### Dynamic partitions
 
-Starting CycleCloud version 3.0.1, we support dynamic partitions. You can make a `nodearray` map to a dynamic partition by adding the following. The `myfeature` could be any desired feature description or more than one feature, separated by a comma.
+Starting with CycleCloud version 3.0.1, the solution supports dynamic partitions. You can make a `nodearray` map to a dynamic partition by adding the following code. The `myfeature` value can be any desired feature description or more than one feature, separated by a comma.
 
 ```ini
       [[[configuration]]]
@@ -71,37 +71,37 @@ Starting CycleCloud version 3.0.1, we support dynamic partitions. You can make a
       slurm.dynamic_config := "-Z --conf \"Feature=myfeature\""
 ```
 
-The shared code snip generates a dynamic partition like the following
+The shared code snippet generates a dynamic partition like the following code:
 
 ```ini
 # Creating dynamic nodeset and partition using slurm.dynamic_config=-Z --conf "Feature=myfeature"
 Nodeset=mydynamicns Feature=myfeature
 PartitionName=mydynamicpart Nodes=mydynamicns
 ```
 
-### Using Dynamic Partitions to Autoscale
+### Using dynamic partitions to autoscale
 
-By default, dynamic partition doesn't include any nodes. You can start nodes through CycleCloud or by running `azslurm resume` manually, they join the cluster using the name you choose. However, since Slurm isn't aware of these nodes ahead of time, it can't autoscale them up.
+By default, a dynamic partition doesn't include any nodes. You can start nodes through CycleCloud or by running `azslurm resume` manually. The nodes join the cluster using the name you choose. However, since Slurm isn't aware of these nodes ahead of time, it can't autoscale them.
 
-Instead, you can also precreate node records like so, which allows Slurm to autoscale them up.
+Instead, you can precreate node records like so, which allows Slurm to autoscale them.
 
 ```bash
 scontrol create nodename=f4-[1-10] Feature=myfeature State=CLOUD
 ```
 
-One other advantage of dynamic partitions is that you can support **multiple VM sizes in the same partition**.
-Simply add the VM Size name as a feature, and then `azslurm` can distinguish which VM size you want to use.
+Another advantage of dynamic partitions is that you can support **multiple VM sizes in the same partition**.
+Simply add the VM size name as a feature, and then `azslurm` can distinguish which VM size you want to use.
 
-**_Note_ The VM Size is added implicitly. You do not need to add it to `slurm.dynamic_config`**
+**_Note_** The VM size is added implicitly. You don't need to add it to `slurm.dynamic_config`.
 
 ```bash
 scontrol create nodename=f4-[1-10] Feature=myfeature,Standard_F4 State=CLOUD
 scontrol create nodename=f8-[1-10] Feature=myfeature,Standard_F8 State=CLOUD
 ```
 
-Either way, once you create these nodes in a `State=Cloud` they become available for autoscaling like other nodes.
+Either way, when you create these nodes in a `State=Cloud` state, they become available for autoscaling like other nodes.
 
-To support **multiple VM sizes in a CycleCloud nodearray**, you can alter the template to allow multiple VM sizes by adding `Config.Mutiselect = true`.
+To support **multiple VM sizes in a CycleCloud node array**, you can change the template to allow multiple VM sizes by adding `Config.Mutiselect = true`.
 
 ```ini
         [[[parameter DynamicMachineType]]]
@@ -112,34 +112,34 @@ To support **multiple VM sizes in a CycleCloud nodearray**, you can alter the te
         Config.Multiselect = true
 ```
 
-### Dynamic Scale down
+### Dynamic scale down
 
-By default, all nodes in the dynamic partition scales down just like the other partitions. To disable dynamic partition, see [SuspendExcParts](https://slurm.schedmd.com/slurm.conf.html).
+By default, all nodes in the dynamic partition scale down just like the other partitions. To disable dynamic partition, see [SuspendExcParts](https://slurm.schedmd.com/slurm.conf.html).
 
 ### Manual scaling
 
-If cyclecloud_slurm detects that autoscale is disabled (SuspendTime=-1), it uses the FUTURE state to denote nodes that're powered down instead of relying on the power state in Slurm. That is, when autoscale is enabled, off nodes are denoted as `idle~` in sinfo. When autoscaling is off, the inactive nodes don’t show up in sinfo. You can still see their definition with `scontrol show nodes --future`.
+If cyclecloud_slurm detects that autoscale is disabled (SuspendTime=-1), it uses the FUTURE state to denote nodes that are powered down instead of relying on the power state in Slurm. When autoscale is enabled, `sinfo` shows off nodes as `idle~`. When autoscale is disabled, `sinfo` doesn't show inactive nodes. You can still see their definition with `scontrol show nodes --future`.
 
-To start new nodes, run `/opt/azurehpc/slurm/resume_program.sh node_list` (for example, htc-[1-10]).
+To start new nodes, run `/opt/azurehpc/slurm/resume_program.sh node_list` (for example, `htc-[1-10]`).
 
-To shutdown nodes, run `/opt/azurehpc/slurm/suspend_program.sh node_list` (for example, htc-[1-10]).
+To shut down nodes, run `/opt/azurehpc/slurm/suspend_program.sh node_list` (for example, `htc-[1-10]`).
 
-To start a cluster in this mode, simply add `SuspendTime=-1` to the supplemental Slurm config in the template.
+To start a cluster in this mode, add `SuspendTime=-1` to the supplemental Slurm config in the template.
 
-To switch a cluster to this mode, add `SuspendTime=-1` to the slurm.conf and run `scontrol reconfigure`. Then run `azslurm remove_nodes && azslurm scale`. 
+To switch a cluster to this mode, add `SuspendTime=-1` to the `slurm.conf` file and run `scontrol reconfigure`. Then run `azslurm remove_nodes` and `azslurm scale`. 
 
 ## Troubleshooting
 
 ### Transitioning from 2.7 to 3.0
 
-1. The installation folder changed
+1. The installation folder changed from
       `/opt/cycle/slurm`
-      ->
-      `/opt/azurehpc/slurm`
+      to
+      `/opt/azurehpc/slurm`.
 
-2. Autoscale logs are now in `/opt/azurehpc/slurm/logs` instead of `/var/log/slurmctld`. Note, that `slurmctld.log` is in this folder.
+1. Autoscale logs are now in `/opt/azurehpc/slurm/logs` instead of `/var/log/slurmctld`. The `slurmctld.log` file is in this folder.
 
-3. The `cyclecloud_slurm.sh` script no longer available. A new CLI tool called `azslurm` replaced `cyclecloud_slurm.sh`, and you can be run as root. `azslurm` also supports autocomplete.
+1. The `cyclecloud_slurm.sh` script is no longer available. A new CLI tool called `azslurm` replaces `cyclecloud_slurm.sh`. You run `azslurm` as root, and it supports autocomplete.
 
       ```bash
       [root@scheduler ~]# azslurm
@@ -167,10 +167,10 @@ To switch a cluster to this mode, add `SuspendTime=-1` to the slurm.conf and run
       wait_for_resume      - Wait for a set of nodes to converge.
       ```
 
-5. CycleCloud no longer creates nodes ahead of time. It only creates them when they're needed.
+1. CycleCloud doesn't create nodes ahead of time. It only creates nodes when you need them.
 
-6. All Slurm binaries are inside the `azure-slurm-install-pkg*.tar.gz` file, under `slurm-pkgs`. They're pulled from a specific binary release. The current binary release is [4.0.0](https://github.com/Azure/cyclecloud-slurm/releases/tag/4.0.0)
+6. All Slurm binaries are inside the `azure-slurm-install-pkg*.tar.gz` file, under `slurm-pkgs`. They're pulled from a specific binary release. The current binary release is [4.0.0](https://github.com/Azure/cyclecloud-slurm/releases/tag/4.0.0).
 
-7. For MPI jobs, the only default network boundary is the partition. Unlike version 2.x, each pertition doesn't include multiple "placement groups". So you only have one colocated VMSS per partition. There's no need for the topology plugin anymore, so the job submission plugin isn't needed either. Instead, submitting to multiple partitions is the recommended option for use cases that require jobs submission to multiple placement groups.
+7. For MPI jobs, the only default network boundary is the partition. Unlike version 2.x, each partition doesn't include multiple "placement groups". So you only have one colocated Virtual Machine Scale Set per partition. There's no need for the topology plugin anymore, so the job submission plugin isn't needed either. Instead, submitting to multiple partitions is the recommended option for use cases that require jobs submission to multiple placement groups.
 
 [!INCLUDE [scheduler-integration](~/articles/cyclecloud/includes/scheduler-integration.md)]
diff --git a/articles/cyclecloud/slurm.md b/articles/cyclecloud/slurm.md
