Merge branch 'main' into release-v0.1.21

Signed-off-by: Matt Richerson <matthew.richerson@hpe.com>

Author: matthew-richerson

docs/guides/rbac-for-users/readme.md

@@ -68,6 +68,7 @@ The kubeconfig file should be placed in a location where HPE employees have read
 The next step is to create ClusterRole and ClusterRoleBinding resources. The ClusterRole provided allows viewing all cluster and namespace scoped resources, but disallows creating, deleting, or modifying any resources.
 
 ClusterRole
+
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
@@ -80,6 +81,7 @@ rules:
 ```
 
 ClusterRoleBinding
+
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
@@ -138,6 +140,7 @@ If the "flux" user requires only the normal WLM permissions, then create and app
 The `dws-workload-manager role is defined in [workload_manager_role.yaml](https://github.com/DataWorkflowServices/dws/blob/master/config/rbac/workload_manager_role.yaml).
 
 ClusterRoleBinding for WLM permissions only:
+
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
@@ -158,6 +161,7 @@ If the "flux" user requires the normal WLM permissions as well as some of the NN
 The `nnf-workload-manager` role is defined in [workload_manager_nnf_role.yaml](https://github.com/NearNodeFlash/nnf-sos/blob/master/config/rbac/workload_manager_nnf_role.yaml).
 
 ClusterRoleBinding for WLM and NNF permissions:
+
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
@@ -173,4 +177,30 @@ roleRef:
   apiGroup: rbac.authorization.k8s.io
 ```
 
+If the "flux" user also requires "get" access to pods and their logs in the "default" namespace, then there is also a namespaced Role resource to provide that access. Create a RoleBinding to associate the "flux" user with the "nnf-workload-manager-coregrp" Role. The "flux" user will be bound to access the NNF resources, across all namespaces, via the ClusterRoleBinding above and it will be bound to access the pod resources, in only the "default" namespace, via this RoleBinding.
+
+```console
+kubectl get role -n default nnf-workload-manager-coregrp
+```
+
+The `nnf-workload-manager-coregrp` role is defined in [workload_manager_nnf_role_ns.yaml](https://github.com/NearNodeFlash/nnf-sos/blob/master/config/rbac-ns/workload_manager_nnf_role_ns.yaml).
+
+RoleBinding for pod permissions:
+
+```yaml
+kind: RoleBinding
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: flux
+  namespace: default
+subjects:
+- kind: User
+  name: flux
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  kind: Role
+  name: nnf-workload-manager-coregrp
+  apiGroup: ""
+```
+
 The WLM should then use the kubeconfig file associated with this "flux" user to access the DataWorkflowServices API and the Rabbit system.

docs/guides/storage-profiles/readme.md

@@ -302,12 +302,17 @@ In general, `scale` gives a simple way for users to get a filesystem that has pe
 - `$VG_NAME` - expands to a volume group name that is controlled by Rabbit software.
 - `$DEVICE_LIST` - expands to a list of space-separated `/dev/<path>` devices. This list will contain the devices that were iterated over for the pvcreate step.
 - `$DEVICE_NUM` - expands to the count of devices in `$DEVICE_LIST`
+- `$DEVICE_NUM-1` - expands to the count of devices in `$DEVICE_LIST` minus 1
+- `$DEVICE_NUM-2` - expands to the count of devices in `$DEVICE_LIST` minus 2
+- `$DEVICE` - expands to the name of a new device. This is used by `vgextend` when repairing a RAID device
 
 ### LVM LV Commands
 
 - `$VG_NAME` - see vgcreate above.
 - `$LV_NAME` - expands to a logical volume name that is controlled by Rabbit software.
 - `$DEVICE_NUM` - expands to a number indicating the number of devices allocated for the volume group.
+- `$DEVICE_NUM-1` - expands to a number indicating the number of devices allocated for the volume group minus 1.
+- `$DEVICE_NUM-2` - expands to a number indicating the number of devices allocated for the volume group minus 2.
 - `$DEVICE1, $DEVICE2, ..., $DEVICEn` - each expands to one of the devices from the `$DEVICE_LIST` above.
 - `$PERCENT_VG` - expands to the size that each LV should be based on a percentage of the total VG size
 - `$LV_SIZE` - expands to the size of the LV in kB in the format expected by `lvcreate`
@@ -330,6 +335,16 @@ In general, `scale` gives a simple way for users to get a filesystem that has pe
 - `$DEVICE_NUM` - expands to a number indicating the number of devices allocated for this storage request.
 - `$DEVICE1, $DEVICE2, ..., $DEVICEn` - each expands to one of the devices from the `$DEVICE_LIST` above.
 
+### zpool replace
+
+- `$DEVICE_NUM` - expands to a number indicating the number of devices allocated for this storage request.
+- `$DEVICE_NUM-1` - expands to a number indicating the number of devices allocated for this storage request minus 1.
+- `$DEVICE_NUM-2` - expands to a number indicating the number of devices allocated for this storage request minus 2.
+- `$DEVICE_LIST` - expands to a list of space-separated `/dev/<path>` devices. This list will contain the devices that were allocated for this storage request.
+- `$POOL_NAME` - expands to a pool name that is controlled by Rabbit software.
+- `$OLD_DEVICE` - expands to the name of a device that is degraded
+- `$NEW_DEVICE` - expands to the name of a new device that can replace the degraded device
+
 ### lustre mkfs
 
 - `$FS_NAME` - expands to the filesystem name that was passed to Rabbit software from the workflow's #DW line.