(Click to open topic with navigation)
The following instructions are applicable to cloud, not HPC, environments.
Removing a tenant is more than just deleting the tenant resource. Tenants are associated with nodes, services, service templates, jobs, vm's, and users. Before deleting the tenant, these other resources must be dealt with in order. The following procedure explains how to deprovision and remove a tenant. Some of the steps may be completed via Moab Viewpoint; other steps require that you use the REST interface or run included command line scripts distributed with MWS. (See Tenant Provisioning Scripts for more information.)
To remove a tenant
Deleting principals associated with the tenant prevents new services from being created on the tenant's nodes, but it does not stop existing services from migrating among those nodes. Creating reservations also prevents new services from being created, and it also prevents migration onto nodes; if users try to create new services, they will be unable to do so (an error results) because the reservation(s) prevent the requested services from being placed.
Once you've copied all the service templates you want to keep, you should delete the remaining service templates from the tenant.
Migrate to another tenant, or delete, any service(s) assigned to the tenant you want to remove. Only container services can be migrated, but when they are, they automatically migrate all their child services as well.
If you have a lot of services assigned to the tenant you want to remove, consider migrating the services in smaller sets to avoid disruptions to data center performance.
It may take some time for all migrations and deletions to complete. Verify that all services have evacuated the tenant's nodes before allowing services from other tenants to use those nodes.
Moab may attempt to migrate services belonging to the tenant you want to remove to available nodes still owned by that tenant. However, the VMs should not have any eligible nodes to migrate to. Following these instructions should minimize the number of migrations, effectively eliminating the case where a VM needs to migrate off and then right back onto a node.
Related Topics