Merge branch 'release/1.6' into feature/image-sig-customization

.spelling

@@ -1071,3 +1071,9 @@ Expat-15
 - troubleshooting/known_issues/antero_node_NID_allocation.md
 # To allow Site Init
 Init
+
+- operations/configuration_management/iSCSI_SBPS_Node_Personalization.md
+enablement
+LUNs
+fileio
+iscsi-sbps-targets-config

operations/boot_orchestration/Limit_the_Scope_of_a_BOS_Session.md

@@ -1,29 +1,39 @@
 # Limit the Scope of a BOS Session
 
-The Boot Orchestration Service \(BOS\) supports an optional --limit parameter when creating a session. This parameter can be used to further limit the nodes that BOS runs against, and is applied to all boot sets.
+The Boot Orchestration Service \(BOS\) supports an optional `limit` parameter when creating a session.
+This parameter can be used to further limit the nodes that BOS runs against, and is applied to all boot sets.
 
-The `--limit` parameter takes a comma-separated list of nodes, groups, or roles in any combination. The BOS session will be limited to run against components that match both the boot set information and one or more of the nodes, groups, or roles listed in the limit.
+If the `session_limit_required` [BOS Option](Options.md) is enabled, then the `limit` parameter is not optional when creating a session.
 
-The table below describes the operations that can be used to further limit the scope of a BOS session. Components are treated as OR operations unless preceded by one of the operations listed in the following table.
+The `limit` parameter takes a comma-separated list of nodes, groups, or roles in any combination. The BOS session will be limited to run against
+components that match both the boot set information and one or more of the nodes, groups, or roles listed in the limit.
+
+When specifying nodes, component names (xnames) must be used. The use of NIDs is not supported. In order to prevent the accidental creation of
+sessions attempting to use NIDs, the `reject_nids` [BOS Option](Options.md) may be enabled.
+
+The table below describes the operations that can be used to further limit the scope of a BOS session. Components are treated as OR operations unless
+preceded by one of the operations listed in the following table.
 
 | Operation | Description                                                                     |
 |-----------|---------------------------------------------------------------------------------|
 | `&`       | Added to the beginning of a group or role to specify an intersection of groups. |
 | `!`       | Added to the beginning of a node, group, or role to exclude it.                 |
-| `all`     | When only trying to exclude a node or group, the limit must start with "all".   |
-
-The table below helps demonstrate the logic used with the --limit parameter and includes examples of how to limit against different nodes, groups, and roles.
-
-| Description            | Pattern                | Targets                           |
-|------------------------|------------------------|-----------------------------------|
-| All nodes              | all \(or leave empty\) | All nodes                         |
-| One node               | node1                  | node1                             |
-| Multiple nodes         | node1,node2            | node1 and node2                   |
-| Excluding a node       | all,!node1             | All nodes except node1            |
-| One group              | group1                 | Nodes in group1                   |
-| Multiple groups        | group1,group2          | Nodes in group1 or group2         |
-| Excluding groups       | group1,!group2         | Nodes in group1 but not in group2 |
-| Intersection of groups | group1,&group2         | Nodes in both group1 and group2   |
-
-The `--limit` parameter for BOS works similarly to the `--ansible-limit` parameter for CFS, as well as the `--limit` parameter for Ansible. Some limitations do apply for those familiar with the Ansible syntax. BOS accepts only a comma-separated list, not colons, and does not support regular expressions in the patterns. For more information on what it means to provide a limit, see [Specifying Hosts and Groups](../configuration_management/Specifying_Hosts_and_Groups.md).
-
+| `all`     | When only trying to exclude a node or group, the limit must start with `all`.   |
+| `*`       | Same as `all`                                                                   |
+
+The table below helps demonstrate the logic used with the `limit` parameter and includes examples of how to limit against different nodes, groups, and roles.
+
+| Description            | Pattern                         | Targets                               |
+|------------------------|---------------------------------|---------------------------------------|
+| All nodes              | `all` or `*` \(or leave empty\) | All nodes                             |
+| One node               | `node1`                         | `node1`                               |
+| Multiple nodes         | `node1,node2`                   | `node1` and `node2`                   |
+| Excluding a node       | `all,!node1`                    | All nodes except `node1`              |
+| One group              | `group1`                        | Nodes in `group1`                     |
+| Multiple groups        | `group1,group2`                 | Nodes in `group1` or `group2`         |
+| Excluding groups       | `group1,!group2`                | Nodes in `group1` but not in `group2` |
+| Intersection of groups | `group1,&group2`                | Nodes in both `group1` and `group2`   |
+
+The `limit` parameter for BOS works similarly to the `--ansible-limit` parameter for CFS, as well as the `limit` parameter for Ansible.
+Some limitations do apply for those familiar with the Ansible syntax. BOS accepts only a comma-separated list, not colons, and does not support regular expressions
+in the patterns. For more information on what it means to provide a limit, see [Specifying Hosts and Groups](../configuration_management/Specifying_Hosts_and_Groups.md).

operations/boot_orchestration/Manage_a_BOS_Session.md

@@ -45,6 +45,7 @@ Sessions also support several other optional arguments:
 
 * `--name`: The session name can be specified. If not set, a random UUID will be generated for the name.
 * `--limit`: Limits the nodes that BOS will run against. For more information see [Limit the Scope of a BOS Session](Limit_the_Scope_of_a_BOS_Session.md)
+    * If the `session_limit_required` [BOS Option](Options.md) is enabled, then the `limit` argument is not optional.
 * `--stage`: Sets `staged_state` for components rather than `desired_state`. This has no immediate effect, but can be applied at a later time. For more information see [Stage Changes with BOS](Stage_Changes_with_BOS.md)
 
 ## List all sessions

operations/boot_orchestration/Options.md

@@ -32,6 +32,7 @@ Example output:
   "max_power_off_wait_time": 300,
   "max_power_on_wait_time": 120,
   "polling_frequency": 15,
+  "reject_nids": false,
   "session_limit_required": false
 }
 ```
@@ -99,9 +100,22 @@ The following are the BOS global options:
 
     How frequently the BOS operators check component state for needed actions (in seconds).
 
+* `reject_nids`
+
+    BOS does not support the use of NIDs to identify nodes -- only xnames.
+    If the `reject_nids` option is enabled, BOS will prevent creation of sessions and session templates that appear to reference NIDs.
+    Specifically, if this option is enabled, then:
+
+    * When creating a session template, if it has any boot sets with a `node_list` that appears to contain a NID, then the creation will fail.
+    * When validating a session template, if it has any boot sets with a `node_list` that appears to contain a NID, then the validation will fail.
+    * When creating a session, if the specified session template has any boot sets with a `node_list` that appears to contain a NID, then the session creation will fail.
+    * When creating a session, if the session limit appears to contain NID values, then the creation will fail.
+
+    This option does NOT have an effect on sessions that were created prior to it being enabled (even if they have not yet started).
+
 * `session_limit_required`
 
-    If enabled, BOS v2 sessions cannot be created without specifying the `limit` parameter.
+    If enabled, BOS sessions cannot be created without specifying the `limit` parameter.
     This can be helpful in avoiding accidental reboots of more components than intended.
     If this option is enabled, it is still possible to effectively create a session with no limit
     by specifying `*` as the limit parameter (if this is done on the command line, it must be

operations/boot_orchestration/Session_Templates.md

@@ -106,6 +106,9 @@ For example:
 "node_list": ["x3000c0s19b1n0", "x3000c0s19b1n1", "x3000c0s19b2n0"]
 ```
 
+NIDs are not supported.
+The `reject_nids` [BOS Option](Options.md) can be enabled in order to prevent accidental creation of session templates that reference NIDs.
+
 #### Node groups
 
 `node_groups` maps to a list of groups defined by the [Hardware State Manager (HSM)](../../glossary.md#hardware-state-manager-hsm).