Skip to content

Latest commit

 

History

History
231 lines (174 loc) · 7.22 KB

Modify_a_Tenant.md

File metadata and controls

231 lines (174 loc) · 7.22 KB

Modifying a Tenant

Overview

This page provides information about how to modify a tenant. Modifications that are supported are limited to:

  • Updating the list of component names (xnames) assigned to this tenant.
  • Adding/deleting childNamespaces.

Modify the existing TAPMS CR

An example of a change to add a component name (xname) to a tenant:

apiVersion: tapms.hpe.com/v1alpha2
kind: Tenant
metadata:
  name: vcluster-blue
spec:
  childnamespaces:
    - user
    - slurm
  tenantname: vcluster-blue
  tenantresources:
    - type: compute
      hsmgrouplabel: blue
      enforceexclusivehsmgroups: true
      xnames:
        - x0c3s5b0n0
        - x0c3s6b0n0
        - x0c3s7b0n0

Apply the modified TAPMS CR

  1. (ncn-mw#) When a tenant CRD is applied, tapms will determine any changes to the tenant, and reconcile any changes to childNamespaces and xnames.

    kubectl apply -n tenants -f <tenant.yaml>

    Example output:

    tenant.tapms.hpe.com/vcluster-blue configured

  2. (ncn-mw#) It can take up to a minute for tapms to reconcile the change. The following command can be used to monitor the status of the tenant:

    kubectl get tenant -n tenants vcluster-blue -o yaml

    Example output:

    apiVersion: tapms.hpe.com/v1alpha2
kind: Tenant
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"tapms.hpe.com/v1alpha2","kind":"Tenant","metadata":{"annotations":{},"name":"vcluster-blue","namespace":"tenants"},"spec":{"childnamespaces":["user","slurm"],"tenantname":"vcluster-blue","tenantresources":[{"enforceexclusivehsmgroups":true,"hsmgrouplabel":"blue","type":"compute","xnames":["x0c3s5b0n0","x0c3s6b0n0"]}]}}
  creationTimestamp: "2022-08-23T18:37:25Z"
  finalizers:
  - tapms.hpe.com/finalizer
  generation: 3
  name: vcluster-blue
  namespace: tenants
  resourceVersion: "3157072"
  uid: 074b6db1-f504-4e9c-8245-259e9b22d2e6
spec:
  childnamespaces:
  - user
  - slurm
  state: Deployed
  tenantname: vcluster-blue
  tenantresources:
  - enforceexclusivehsmgroups: true
    hsmgrouplabel: blue
    type: compute
    xnames:
    - x0c3s5b0n0
    - x0c3s6b0n0
    - x0c3s7b0n0
status:
  childnamespaces:
  - vcluster-blue-user
  - vcluster-blue-slurm
  tenantresources:
  - enforceexclusivehsmgroups: true
    hsmgrouplabel: blue
    type: compute
    xnames:
    - x0c3s5b0n0
    - x0c3s6b0n0
    - x0c3s7b0n0
  uuid: 074b6db1-f504-4e9c-8245-259e9b22d2e6

  3. (ncn-mw#) The cray command can now be used to display changes to the HSM group:

    cray hsm groups describe blue --format toml

    Example output:

    label = "blue"
description = ""
exclusiveGroup = "tapms-exclusive-group-label"
tags = [ "vcluster-blue",]

[members]
ids = [ "x0c3s5b0n0", "x0c3s6b0n0", "x0c3s7b0n0"]

Modify the slurm operator CR

To make changes to a Slurm tenant deployment, first update the Slurm custom resource file. The Slurm operator will attempt to reconcile the following changes:

  • Changing the munge key length.
  • Changing the slurmctld PVC.
  • Changing the Percona XtraDB, slurmctld, or slurmdbd deployments.

Apply the slurm operator CR

(ncn-mw#) To update the Slurm custom resource, apply the changed file:

kubectl apply -f <cluster>.yaml

Once the custom resource has been updated, the Slurm operator will attempt to update the relevant Kubernetes resources to reflect the changes.

Modify the Slurm configuration

If the list of nodes assigned to a tenant changes, the Slurm configuration must be updated by rerunning the Kubernetes job that generates it. This procedure can also be used to change Slurm configuration settings, or add new Slurm configuration files.

  1. (ncn-mw#) Get the current configuration.

    kubectl get configmap -n slurm-operator <cluster>-config-templates -o yaml >slurm-config-templates.yaml

  2. (ncn-mw#) Make desired edits.

    • To edit an existing configuration file (for example, slurm.conf):

      yq r slurm-config-templates.yaml 'data."slurm.conf"' >slurm.conf
# Edit slurm.conf
yq w -i slurm-config-templates.yaml 'data."slurm.conf"' "$(cat slurm.conf)"

    • To add a new configuration file (for example, topology.conf):

      yq w -i slurm-config-templates.yaml 'data."topology.conf"' "$(cat topology.conf)"

  3. (ncn-mw#) Apply changes to the configuration templates.

    kubectl apply -f slurm-config-templates.yaml

  4. (ncn-mw#) Rerun the Slurm configuration job.

    kubectl get job -n slurm-operator <cluster>-slurm-config -o yaml >slurm-config.yaml
yq d -i slurm-config.yaml spec.template.metadata
yq d -i slurm-config.yaml spec.selector
kubectl delete -f slurm-config.yaml
kubectl create -f slurm-config.yaml

  5. (ncn-mw#) Once the job has completed, reconfigure Slurm.

    SLURMCTLD_POD=$(kubectl get pod -n <namespace> -lapp.kubernetes.io/name=slurmctld -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n <namespace> ${SLURMCTLD_POD} -c slurmctld -- scontrol reconfigure

Update component records in BOS

Any nodes that are moving from one tenant to another should have their records cleared in BOS. Clearing the desired state will have the secondary effect of causing BOS to shutdown the node. This prevents a tenant using a node that is booted with another tenant's boot artifact or configuration.

This procedure requires the Cray CLI to be configured on the node where it is being performed. See Configure the Cray CLI.

  1. (ncn-mw#) Clear the desired state.

    • For a single component changing tenants, use the following command:

      cray bos v2 components update --enabled true --clear-pending-state <xname>

    • For multiple components changing tenants, use the following command:

      cray bos v2 components updatemany --enabled true --clear-pending-state --filter-ids <xname1>,<xname2>,...

  2. (ncn-mw#) Wait until the components reach a stable state.

    Because the previous step cleared the desired state, the stable state indicates that the components are powered off.

    • For checking a single component, use the following command:

      cray bos v2 components describe <xname> --format json | jq .status.status

    • For checking multiple components, use the following command:

      cray bos v2 components list --ids <xname1>,<xname2>,... --format json | jq '.[] | .status.status'