Skip to content

Commit

Permalink
CASMCMS-7687: Improve BOS documentation (#5364)
Browse files Browse the repository at this point in the history
(cherry picked from commit 83d875b)
  • Loading branch information
mharding-hpe authored Sep 13, 2024
1 parent 6268b85 commit 6b8a87b
Show file tree
Hide file tree
Showing 2 changed files with 28 additions and 21 deletions.
47 changes: 27 additions & 20 deletions operations/boot_orchestration/Limit_the_Scope_of_a_BOS_Session.md
Original file line number Diff line number Diff line change
@@ -1,29 +1,36 @@
# 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.
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.

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.
When specifying nodes, component names (xnames) must be used. The use of NIDs is not supported.

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).
2 changes: 1 addition & 1 deletion operations/boot_orchestration/Session_Templates.md
Original file line number Diff line number Diff line change
Expand Up @@ -92,7 +92,7 @@ The `node_list`, `node_groups`, or `node_role` values can each be specified as a

#### Node list

`node_list` maps to a list of nodes identified by component names (xnames).
`node_list` maps to a list of nodes identified by component names (xnames). NIDs are not supported.

For example:

Expand Down

0 comments on commit 6b8a87b

Please sign in to comment.