9. Tenant Management

Tenants are a construct of Robin Platform that allow users to be organized (separated) into discrete groups based on function or business requirements. A tenant user is only allowed to access and make use of system resources (storage, CPUs, and memory) that have been assigned to their respective tenant. In addition, all applications the user deploys, all bundles they upload, etc. are bound to the tenant they were logged into at the time of creation.

During installation, Robin Platform creates a special tenant called the Administrators tenant. This is a fully functional tenant that can have system resources and users assigned to it. But the Administrators tenant is unique in a number of ways:

  • The Administrators tenant cannot be renamed or deleted.

  • Resource pools and IP-Pools are automatically assigned to the Administrators tenant.

  • A user can only be assigned the role of superadmin if they are a member of the Administrators tenant. The same user could be made a member of other tenants, but they can only be assigned the role of tenantadmin or user for those tenants.

  • The admin user created during installation is automatically made a member of the Administrators tenant.

Topics covered in this chapter:

robin tenant add

Add a tenant

robin tenant remove

Remove a tenant

robin tenant list

List tenants

robin tenant rename

Rename a tenant

robin tenant update-description

Update the tenant description

robin tenant add-rpools

Assign one or more resource pools to a tenant

robin tenant remove-rpools

Remove one or more rpools from a tenant

robin tenant add-ip-pools

Assign one or more ip-pools to a tenant

robin tenant remove-ip-pools

Remove one or more ip-pools from a tenant

robin tenant add-users

Add one or more users to a tenant and assign them a tenant role and user capabilities

robin tenant remove-users

Remove a user from a tenant

robin tenant add-user-capabilities

Assign one or more capabilities to a tenant user

robin tenant update-user-capabilities

Update a tenant user’s user capabilities

robin tenant remove-user-capabilities

Remove one or more capabilities from a tenant user

robin tenant update-limits

Update one or more of the limits that control app creation for a tenant and for users of a tenant.

robin tenant update-rpool-limits

Update one or more of the limits that control resource allocation for a tenant and for users of a tenant.

9.1. Add a tenant

Run the following command to add a tenant to the Robin Platform cluster:

# robin tenant add <tenant_name>
                   --rpools <resource_pools>
                   --ip-pools <ip_pools>
                   --description <description>

tenant_name

Name of tenant

--rpools <resource_pools>

Comma-separated list of resource pools (rpools) to assign to the tenant

--ip-pools <ip_pools>

Comma separated list of IP pools (ip_pools) to assign to the tenant

--description <description>

Description of the tenant. The description string must be placed between quotes.

Example:

# robin tenant add t2 --rpools default --ip-pools robin-default
Registered tenant 't2'.

Note

  • The ability to add tenants is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users assigned the superadmin role) have permission to do so.

Adds a tenant to the Robin Platform cluster.

End Point: /api/v3/robin_server/tenants

Method: POST

URL Parameters: None

Data Parameters:

  • tenant: <dict_of_key_value_pairs>

    • name: <tenant_name> - This mandatory mandatory key value pairing within the tenant dictionary specifies the name of the tenant to be added.

    • rpools: <list_of_rpools> - Utilizing this key value pairing within the tenant dictionary, by specifiying a list of resource pool names, results in the aforementioned resource pools being assigned to the tenant upon creation.

    • ip_pools: <list_of_ip_pools> - Utilizing this key value pairing within the tenant dictionary, by specifiying a list of IP pool names, results in the aforementioned IP pools being assigned to the tenant upon creation.

    • description: <description> - Utilizing this key value pairing within the tenant dictionary, by specifiying a description string, results in the tenant being created with the aforementioned description.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error), 409 (Duplicate Resource Error)

Example Response:

Output
{
   "message":"Registered tenant 't2'.\n"
}

9.2. Remove a tenant

Run the following command to remove a tenant from the Robin Platform cluster:

# robin tenant remove <tenant_name>

tenant_name

Name of tenant to remove

Example:

# robin tenant remove t2
Are you sure you want to delete [y/n] ? y
Unregistered tenant 't2'

Note

  • The ability to remove tenants is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users assigned the superadmin role) have permission to do so.

  • All resource pools and IP-Pools must be removed from a tenant before it can be removed from the cluster.

Removes a tenant from the Robin Platform cluster.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: DELETE

URL Parameters: None

Data Parameters: None

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Unregistered tenant 't2'"
}

9.3. List tenants

Run the following command to list tenants:

# robin tenant list [<tenant_name>]
                    --all
                    --full

tenant_name

Name of tenant to remove

--all

Include deleted tenants in return collection

--full

Display additional information about each tenant

Example 1: List all tenants

# robin tenant list
Name           | Resource Pools | IP Pools      | Protected | TenantType         | Description
---------------+----------------+---------------+-----------+--------------------+-----------------------
Administrators | default        | robin-default | *         | ROBIN_TENANT       | Administrators Tenant
t1             | default        | robin-default |           | ROBIN_TENANT       |

Example 2: List additional details for a tenant

# robin tenant list t1 --full
Name | Resource Pools | IP Pools      | Protected | TenantType   | Description
-----+----------------+---------------+-----------+--------------+-------------
t1   | default        | robin-default |           | ROBIN_TENANT |

users: admin1,user1,user2

limits:

rpool_limits:

Lists all tenants.

End Point: /api/v5/robin_server/tenants/

Method: GET

URL Parameters: None

Data Parameters: None

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 401 (Unauthorized Error)

Example Response:

Output
{
   "items":[
      {
         "users":[
            {
               "last_name":"Systems",
               "first_name":"Robin",
               "role":"tenantadmin",
               "email":null,
               "source":"local",
               "username":"robin"
            }
         ],
         "protected":true,
         "limits":null,
         "description":"Administrators Tenant",
         "rpool_limits":[

         ],
         "id":1,
         "tenant_type":"ROBIN_TENANT",
         "rpools":[
            "default"
         ],
         "name":"Administrators",
         "ip_pools":[
            "robin-default"
         ],
         "deleted":false
      },
      {
         "users":[

         ],
         "protected":false,
         "limits":null,
         "description":"First additional tenant",
         "rpool_limits":[

         ],
         "id":2,
         "tenant_type":"ROBIN_TENANT",
         "rpools":[
            "default"
         ],
         "name":"t1",
         "ip_pools":[
            "robin-default"
         ],
         "deleted":false
      },
      {
         "users":[
            {
               "last_name":"Systems",
               "first_name":"Robin",
               "role":"tenantadmin",
               "email":null,
               "source":"local",
               "username":"robin"
            }
         ],
         "protected":false,
         "limits":null,
         "description":"Second tenant ",
         "rpool_limits":[

         ],
         "id":3,
         "tenant_type":"ROBIN_TENANT",
         "rpools":[
            "default"
         ],
         "name":"t2",
         "ip_pools":[
            "robin-default"
         ],
         "deleted":false
      }
   ]
}

9.4. Rename a tenant

Run the following command to rename a tenant:

# robin tenant rename <tenant_name> <new_tenant_name>

tenant_name

Name of tenant to rename

new_tenant_name

New name for the tenant

Example:

# robin tenant rename t2 tenant2
Tenant 't2' renamed to 'tenant2'.

Note

  • The ability to rename tenants is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users assigned the superadmin role) have permission to do so.

  • If there are any applications bound to the tenant, it cannot be renamed.

Renames an existing tenant.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: rename - This mandatory field within the payload specifies that the rename operation is to be performed.

  • new_name: <new_tenant_name> - This mandatory field within the payload specifies the new name for the specified tenant.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Tenant 't2' renamed to 'tenant2'."
}

9.5. Update tenant description

Run the following command to change a tenant’s description:

# robin tenant change-description <tenant_name> <new_description>

tenant_name

Name of tenant

new_description

New description for the tenant

Example:

# robin tenant update-description t2 "Tenant for second group"
Description for tenant 't2' has been updated

Note

The ability to change a tenant’s description is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users assigned the superadmin role) have permission to do so.

Updates a tenants description.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: update_description - This mandatory field within the payload specifies that the tenant’s description is to be updated.

  • new_description: <new_tenant_desc> - This mandatory field within the payload specifies the new description for the specified tenant.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Description for tenant 't2' has been updated\n"
}

9.6. Add resource pools to a tenant

Run the following command to add one or more resource pools to a tenant:

# robin tenant add-rpools <tenant_name> <resource_pools>

tenant_name

Name of tenant to add resource pools to

resource_pools

Comma separated list of resource pools to add

Example:

# robin tenant add-rpools t2 default
Successfully added one or more rpools to tenants

Note

The ability to add resource pools to a tenant is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users assigned the superadmin role) have permission to do so.

Adds one or more resource pools to a tenant.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: add_rpools - This mandatory field within the payload specifies that the add resource pools operation is to be performed.

  • rpools: <list_of_rpool_names> - This mandatory field within the payload specifies a comma seperated list of resource pools that should be added to the tenant.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully added one or more rpools to tenants"
}

9.7. Remove resource pools from a tenant

Run the following command to remove one or more resource pools from a tenant:

# robin tenant remove-rpools <tenant_name> <resource_pools>

tenant_name

Name of tenant to remove resource pools from

resource_pools

Command separated list of resource pools to remove

Example:

# robin tenant remove-rpools t2 default
Successfully removed one or more rpools from tenants

Note

  • The ability to add resource pools to a tenant is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users assigned the superadmin role) have permission to do so.

  • A resource pool cannot be removed from a tenant if there are any applications owned by the tenant referencing it.

Removes one or more resource pools from a tenant.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: remove_rpools - This mandatory field within the payload specifies that the remove resource pools operation is to be performed.

  • rpools: <list_of_rpool_names> - This mandatory field within the payload specifies a comma seperated list of resource pools that should be removed from the tenant.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully removed one or more rpools from tenants"
}

9.8. Add IP-Pools to a tenant

Run the following command to add one or more IP-Pools to a tenant:

# robin tenant add-ip-pools <tenant_name> <ip_pools>

tenant_name

Name of tenant to add resource pools to

ip_pools

Command separated list of IP-Pools to add

Example:

# robin tenant add-ip-pools t1 robin-default
Successfully added one or more ip_pools to tenants

Note

The ability to add IP-pools to a tenant is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users assigned the superadmin role) have permission to do so.

Adds one or more IP pools to a tenant.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: add_ip_pools - This mandatory field within the payload specifies that the add IP pools operation is to be performed.

  • rpools: <list_of_ip_pool_names> - This mandatory field within the payload specifies a comma seperated list of IP pools that should be added to the tenant.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully added one or more ip_pools to tenants"
}

9.9. Remove IP-Pools from a tenant

Run the following command to remove one or more IP-Pools from a tenant:

# robin tenant remove-ip-pools <tenant_name> <ip_pools>

tenant_name

Name of tenant to remove resource pools from

ip_pools

Command separated list of resource pools to remove

Example:

# robin tenant remove-ip-pools t2 robin-default
Successfully removed one or more ip_pools from tenants

Note

  • The ability to remove IP-Pools from a tenant is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users assigned the superadmin role) have permission to do so.

  • An IP-Pool cannot be removed from a tenant if there are any applications instances from the tenant referencing it.

Removes one or more IP pools from a tenant.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: remove_ip_pools - This mandatory field within the payload specifies that the remove IP pools operation is to be performed.

  • rpools: <list_of_ip_pool_names> - This mandatory field within the payload specifies a comma seperated list of IP pools that should be removed from the tenant.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully removed one or more ip_pools from tenants"
}

9.10. Add Users to a Tenant

Run the following command to add one or more users to a tenant:

# robin tenant add-users <tenant> <users> <tenant_role> [<user_capabilities>]
                                                        --namespaces <namespaces>
                                                        --import-namespace

tenant_name

Name of tenant to add the users to

users

Comma seperated list of users to be added to the tenant

tenant_role

Tenant role to assign to the users

user_capabilities

A comma separated list of tenant specific capabilities to assign to the users being added. Note that if no user_capabilities are specified, then full capabilities for the specified role will be assigned. If it’s desired that no capabilities be granted to the users then specify NoCapabilities. Note that this list of user capabilities will be assigned to all users being added to the tenant.

--namespaces <namespaces>

A comma separated list of primary namespaces to assign to users when adding them to a tenant. Namespaces should be specified in the following format: <username>:<namespace>. If no namespace is supplied for a user, then one will be created and assigned to them. If the namespace does not already exist, it will be created. If the namespace is already bound to the tenant, then its ownership will be transferred to the newly added user (along with any applications that have been deployed in this namespace).

--import-namespace

Import the specified Kubernetes namespaces if they exists.

Example 1: Add a user to a tenant

# robin tenant add-user t2 user1 user
Successfully added one or more users to tenant

Example 2: Add two users to a tenant and specify a primary namespace for each user

# robin tenant add-users t3 user1,user2 user --namespaces user1:user1-ns,user2:user2-ns
Successfully added one or more users to tenant 't3'

# robin namespace list --tenant t3
+--------------+--------------+-------------------+
| Name         | Owner/Tenant | Primary Namespace |
+--------------+--------------+-------------------+
| t004-u000011 | admin3/t3    | True              |
| user5-ns     | admin3/t3    | False             |
| user2-ns     | user2/t3     | True              |
| user1-ns     | user1/t3     | True              |
+--------------+--------------+-------------------+

Note

  • The ability to add a user to a tenant is subject to Role Based Access Control (RBAC). By default, only Cluster Administrators (users assigned the superadmin role and users assigned the tenantadmin role for the specified tenant) have permission to do so.

  • Only users that have been added to the Robin Platform cluster can be added to a tenant.

  • The user and tenantadmin roles can be assigned to a user that is being added to any tenant.

  • The superadmin role can only be assigned a user that is being added to the Administrators tenant.

  • Support for Helm 2 and Tiller is deprecated and will be removed in the next release.

Adds one or more users to a tenant.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: add_users - This mandatory field within the payload specifies that the add user operation is to be performed.

  • replacement_users: <list_of_dicts>

    • username: <user_name> - This mandatory field within the dictionary specifies the name of the user to add to the tenant.

    • tenant_role: <tenant_role> - This mandatory field within the dictionary specifies the role of the user within the tenant. Valid options include: ‘superadmin’, ‘tenantadmin’ and ‘user’.

    • namespace: <namespace> - Utilizing this parameter within the dictionary, by specifying the name of a namespace, results in the specified namespace being set as the users primary namespace within the tenant. Note if no namespace is supplied, then one will be created and assigned. If the specified namespace does not already exist, it will be created. If the namespace is already bound to the tenant, then its ownership will be transferred to the newly added user (along with any applications that have been deployed in this namespace).

    • import_namespace: true - Utilizing this parameter within the dictionary indicates that the specified Kubernetes namespace should be imported. Note this parameter is only valid when used alongside the namespace parameter described above.

    • user_capabilities: <list_of_capabilities> - Utilizing this parameter within the dictionary, by specifying a comma seperated list of capabilities, results in the aforementioned capabilties being assigned to the newly added user. Note if this parameter is not used, then full capabilities for the specified role will be assigned to the user. If it’s desired that no capabilities be granted to the user then specify ‘NoCapabilities’ within the list.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully added one or more users to tenant"
}

9.11. Remove One or More Users from a Tenant

Run the following command to remove a user from a tenant:

# robin tenant remove-users <tenant> <users> [<replacement_user>]
                                             --keep-k8s-namespaces

tenant

Name of tenant the users will be removed from

users

Comma separated list of users being removed (can also be a single username)

replacement_user

The username of the tenant user who will be assigned ownership of all objects owned by the removed users.

--keep-k8s-namespaces

Don’t delete a user’s Kubernetes namespaces when removing them.

Example 1: Remove a user from a tenant

# robin tenant remove-user t1 user1
Are you sure you want to delete [y/n] ? y
Successfully removed one or more users from tenant

Example 2: Remove a user from a tenant and reassign ownership of ther apps to another user

# robin app list
ROBIN Bundle Apps:

+---------------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+
| Name          | Owner/Tenant | Type   | Parent | Resource Pool | Vnodes | CPU | GPU | Memory (GB) | Status | LastOpr | Health    | Error |
+---------------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+
| mysql-t3-u5-1 | user5/t3     | MASTER | -      | default       |      1 |   4 |   0 |           4 | Ready  | ONLINE  | Unhealthy |     0 |
+---------------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+

# robin tenant remove-users t3 user5 user6 -y
# Successfully removed one or more users from tenant 't3'

# robin app list
ROBIN Bundle Apps:

+---------------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+
| Name          | Owner/Tenant | Type   | Parent | Resource Pool | Vnodes | CPU | GPU | Memory (GB) | Status | LastOpr | Health    | Error |
+---------------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+
| mysql-t3-u5-1 | user6/t3     | MASTER | -      | default       |      1 |   4 |   0 |           4 | Ready  | ONLINE  | Unhealthy |     0 |
+---------------+--------------+--------+--------+---------------+--------+-----+-----+-------------+--------+---------+-----------+-------+

Note

  • The ability to remove a user from a tenant is subject to Role Based Access Control (RBAC). By default, only Cluster and Tenant Administrators (users assigned the superadmin role and users assigned the tenantadmin role for the specified tenant) have permission to do so.

  • A user cannot be removed from a tenant if they own any tenant-bound objects, such as applications, bundles, etc.

  • A user cannot be removed from their last tenant (add the user to another tenant before removing them from their current one).

Updates the capabilities assigned to a tenant user.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: remove_users - This mandatory field within the payload specifies that the remove user operation is to be performed.

  • delete_namespaces: [true|false] - This mandatory field within the payload specifies whether or not the deletion of the user(s) results in their associated namespaces being also being deleted.

  • user_list: <list_of_user_names> - This mandatory field within the payload specifies a list containing the names of the users that should be removed from the specified tenant.

  • replacement_user: <replacement_user> - Utilizing this parameter within the payload, by specifying the username of the replacement user, results in the specified user becoming the owner of all the application related objects of the deleted users.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully removed one or more users from tenant"
}

9.12. Add user capabilities

Run the following command to give a tenant user additional capabilities:

# robin tenant add-user-capabilities <tenant_name> <username> <user_capabilities>

tenant_name

Name of tenant to add the user to

username

The username of user being added

user_capabilities

Comma separated list of tenant specific capabilities to assign to the user. If it’s desired that no capabilities be granted to the user then specify ‘NoCapabilities’ on the command line.

Note

To view a list of all user capabilities review the section detailed here.

Example:

# robin tenant add-user-capabilities t2 user1 CreateBundles
Successfully added one or more user capabilities

Note

  • The ability to remove a user from a tenant is subject to Role Based Access Control (RBAC). By default, only Cluster and Tenant Administrators (users assigned the superadmin role and users assigned the tenantadmin role for the specified tenant) have permission to do so.

  • Not all user capabilities can be added to users who have been assigned tenantadmin or user roles. Certain capabilities can only be added to users who have been assigned the superadmin role.

Adds additional capabilities to a tenant user.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: add_user_capabilities - This mandatory field within the payload specifies that the add capabilities peration is to be performed.

  • tenant_name: <tenant_name> - This mandatory field within the payload specifies the name of the tenant in which the users will be modified.

  • users: <list_of_user_names> - This mandatory field within the payload specifies a comma seperated list of users that should be modified within the tenant.

  • user_capabilities: <list_of_capabilities> - This mandatory field within the payload specifies a comma seperated list of capabilities that should be added to each aforementioned user.

Note

To view a list of all user capabilities review the section detailed here.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully added one or more user capabilities"
}

9.13. Update user capabilities

Run the following command to update a tenant users capabilities:

# robin tenant update-user-capabilities <tenant_name> <username> <user_capabilities>

tenant_name

Name of tenant the capabilities apply to

username

The username of the user who’s capabilities will be updated

user_capabilities

Comma separated list of tenant specific capabilities to assign to the user. If it’s desired that no capabilities be assigned to the user then specify ‘NoCapabilities’ on the command line.

Note

To view a list of all user capabilities review the section detailed here.

Example:

# robin tenant update-user-capabilities t2 user1 CreateBundles,CreateApplications
Successfully added one or more user capabilities

Note

  • All the capabilities the user currently has will be overwritten by those specified as part of the command.

  • The ability to remove a user from a tenant is subject to Role Based Access Control (RBAC). By default, only Cluster and Tenant Administrators (users assigned the superadmin role and users assigned the tenantadmin role for the specified tenant) have permission to do so.

  • Not all user capabilities can be added to users who have been assigned tenantadmin or user roles. Certain capabilities can only be added to users who have been assigned the superadmin role.

Updates the capabilities assigned to a tenant user.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: update_user_capabilities - This mandatory field within the payload specifies that the update capabilities operation is to be performed.

  • tenant_name: <tenant_name> - This mandatory field within the payload specifies the name of the tenant in which the users will be modified.

  • users: <list_of_user_names> - This mandatory field within the payload specifies a list containing the name of the user that should be modified within the tenant. Note this list should only contain one username.

  • user_capabilities: <list_of_capabilities> - This mandatory field within the payload specifies a comma seperated list of capabilities that should be assigned to the user. Note all the capabilities the user currently has will be overwritten by those specified here.

Note

To view a list of all user capabilities review the section detailed here.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully added one or more user capabilities"
}

9.14. Remove user capabilities

Run the following command to remove capabilities from a tenant user:

# robin tenant remove-user-capabilities <tenant_name> <username> <user_capabilities>

tenant_name

Name of tenant to add the user to

username

The username of user being added

user_capabilities

Comma separated list of tenant specific capabilities to unassign from the user

Note

To view a list of all user capabilities review the section detailed here.

Example:

# robin tenant remove-user-capabilities t2 user1 CreateBundles
Are you sure you want to delete [y/n] ? y
Successfully removed one or more user capabilities

Note

The ability to remove capabilities from a tenant user is subject Role Based Access Control (RBAC). By default, only Cluster and Tenant Administrators (users assigned the superadmin role and users assigned the tenantadmin role for the specified tenant) have permission to do so.

Removes capabilities from a tenant user.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: remove_user_capabilities - This mandatory field within the payload specifies that the remove capabilities operation is to be performed.

  • tenant_name: <tenant_name> - This mandatory field within the payload specifies the name of the tenant in which the users will be modified.

  • users: <list_of_user_names> - This mandatory field within the payload specifies a list containing the name of the user that should be modified within the tenant. Note this list should only contain one username.

  • user_capabilities: <list_of_capabilities> - This mandatory field within the payload specifies a comma seperated list of capabilities that should be unassigned from the user.

Note

To view a list of all user capabilities review the section detailed here.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully removed one or more user capabilities"
}

9.15. Update tenant limits

By default, no limits are set that control app creation for a tenant. In order to update/set tenant limits (use the --full flag when listing tenants to view and limits that have been set), issue the following command:

Note

Limits set for a tenant take precedence over user limits.

# robin tenant update-limits <tenant_name>
                             --max-apps-per-tenant <max_apps_per_tenant>
                             --max-apps-per-user <max_apps_per_user>
                             --max-clones-per-tenant <max_clones_per_tenant>
                             --max-clones-per-user <max_clones_per_user>
                             --max-snapshots-per-tenant <max_snapshots_per_tenant>
                             --max-snapshots-per-user <max_snapshots_per_user>

tenant_name

Name of tenant to update limits for

--max-apps-per-tenant <max_apps_per_tenant>

Maximum number of apps that can be created by all users of the tenant combined

--max-apps-per-user <max_apps_per_user>

Maximum number of apps that can be created by each tenant user

--max-clones-per-tenant <max_clones_per_tenant>

Maximum number of clones that can be created by all users of the tenant combined

--max-clones-per-user <max_clones_per_user>

Maximum number of clones that can be created by each tenant user

--max-snapshots-per-tenant <max_snapshots_per_tenant>

Maximum number of snapshots that can be created by all users of the tenant combined

--max-snapshots-per-user <max_snapshots_per_user>

Maximum number of snapshots that can be created by each tenant user

Note

To turn off limits for a particular resource type, specify ‘NONE’ instead of a limit amount.

Example:

# robin tenant update-limits t2 --max-apps-per-tenant 10
Successfully updated limits for tenant 't2'

Note

The ability to set tenant limits is subject to Role Based Access Control (RBAC). By default, only Cluster and Tenant Administrators (users assigned the superadmin role and users assigned the tenantadmin role for the specified tenant) have permission to do so.

Tenant Limit Error Message

You can see an error message when a tenant exceeds limits in the following places:

  • If ResouceQouta is set, the limit exceed error message for Pods appears when you run the kubectl get event -n <namespace> command.

  • If ResourceQuota is not set, the limit exceeded error message for Pods appears in the Pod description , events, or on the console during app deployment.

Updates/sets the limits for a tenant. By default, no limits are set that control app creation for a tenant.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: update_limits - This mandatory field within the payload specifies that the update limits operation is to be performed.

  • limits: <dict_of_attributes_to_update>

    • max_apps_per_tenant: <max_tenant_apps> - Utilizing this parameter within the dictionary results in the maximum number of applications that can be created by all users of the tenant combined being set to the integer specified.

    • max_apps_per_user: <max_tenant_user_apps> - Utilizing this parameter within the dictionary results in the maximum number of applications that can be created by each tenant user being set to the integer specified.

    • max_clones_per_tenant: <max_tenant_clones> - Utilizing this parameter within the dictionary results in the maximum number of clones that can be created by all users of the tenant combined being set to the integer specified.

    • max_clones_per_user: <max_tenant_user_clones> - Utilizing this parameter within the dictionary results in the maximum number of clones that can be created by each tenant user being set to the integer specified.

    • max_snapshots_per_tenant: <max_tenant_snaps> - Utilizing this parameter within the dictionary results in the maximum number of snapshots that can be created by all users of the tenant combined being set to the integer specified.

    • max_snapshots_per_user: <max_tenant_user_snaps> - Utilizing this parameter within the dictionary results in the maximum number of snapshots that can be created by each tenant user being set to the integer specified.

Note

To turn off limits for a particular resource type, specify ‘NONE’ instead of a limit amount.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully updated limits for tenant 'Administrators'"
}

9.16. Update resource pool limits

By default, no resource limits are set for the resource pools associated with tenants. In order to update/set resource pool limits for a tenant (use the --full flag when listing tenants to view and limits that have been set), issue the following command:

# robin tenant update-rpool-limits <tenant_name> <resource_pool_name>
                                                 --max-cores-per-tenant <max_cores_per_tenant>
                                                 --max-cores-per-app <max_cores_per_app>
                                                 --max-mem-per-tenant <max_mem_per_tenant>
                                                 --max-mem-per-app <max_mem_per_app>
                                                 --max-hdd-per-tenant <max_hdd_per_tenant>
                                                 --max-hdd-per-app <max_hdd_per_app>
                                                 --max-ssd-per-tenant <max_ssd_per_tenant>
                                                 --max-ssd-per-app <max_ssd_per_app>

Note

It is possible that not enough resources exist to satisfy the allocation request for a given app, even if the requested amount falls below the resource limits.

tenant_name

Name of tenant to update limits for

resource_pool_name

The resource pool to update limits for

--max-cores-per-tenant <max_cores_per_tenant>

Maximum number of cores that can be allocated from the resource pool by all users of the tenant combined

--max-cores-per-app <max_cores_per_app>

Maximum number of cores that can be allocated from the resource pool during app creation by each tenant user

--max-mem-per-tenant <max_mem_per_tenant>

Maximum amount of memory that can be allocated from the resource pool by all users of the tenant combined

--max-mem-per-app <max_mem_per_app>

Maximum amount of memory that can be allocated from the resource pool during app creation by each tenant user

--max-hdd-per-tenant <max_hdd_per_tenant>

Maximum amount of HDD storage that can be allocated from the resource pool by all users of the tenant combined

--max-hdd-per-app <max_hdd_per_app>

Maximum amount of HDD storage that can be allocated from the resource pool during app creation by each tenant user

--max-ssd-per-tenant <max_ssd_per_tenant>

Maximum amount of SSD storage that can be allocated from the resource pool by all users of the tenant combined

--max-ssd-per-app <max_ssd_per_app>

Maximum amount of SSD storage that can be allocated from the resource pool during app creation by each tenant user

--max-gpus-per-tenant <max_cores_per_tenant>

Maximum number of gpus that can be allocated from the resource pool by all users of the tenant combined

--max-gpus-per-app <max_cores_per_app>

Maximum number of gpus that can be allocated from the resource pool during app creation by each tenant user

Note

To turn off limits for a particular resource type, specify ‘NONE’ instead of a limit amount.

Example:

# robin tenant update-rpool-limits t1 default --max-cores-per-tenant 16
Successfully updated rpool limits for tenant 't1'

Note

The ability to set tenant resource pool limits is subject to Role Based Access Control (RBAC). By default, only Cluster and Tenant Administrators (users assigned the superadmin role and users assigned the tenantadmin role for the specified tenant) have permission to do so.

Updates/sets the resource pool limits for a tenant. By default no resource limits are set for the resource pools associated with tenants.

End Point: /api/v3/robin_server/tenants/<tenant_name>

Method: PUT

URL Parameters: None

Data Parameters:

  • action: update_rpool_limits - This mandatory field within the payload specifies that the update resource pools operation is to be performed.

  • rpool: <rpool_name> - This mandatory field within the payload specifies the resource pool, associated with the aforementioned tenant, to update.

  • limits: <dict_of_attributes_to_update>

    • max_cores_per_tenant: <max_tenant_cores> - Utilizing this parameter within the dictionary results in the maximum number of cores that can be allocated from the resource pool by all users of the tenant combined being set to the integer specified.

    • max_cores_per_app: <max_app_cores> - Utilizing this parameter within the dictionary results in the maximum number of cores that can be allocated from the resource pool resource pool during app creation by each tenant user being set to the integer specified.

    • max_mem_per_tenant: <max_tenant_mem> - Utilizing this parameter within the dictionary results in the maximum amount of memory that can be allocated from the resource pool by all users of the tenant combined being set to the value specified. This value should be an integer and in bytes.

    • max_mem_per_app: <max_app_mem> - Utilizing this parameter within the dictionary results in the maximum amount of memory that can be allocated from the resource pool resource pool during app creation by each tenant user being set to the value specified. This value should be an integer and in bytes.

    • max_hdd_per_tenant: <max_tenant_hdd> - Utilizing this parameter within the dictionary results in the maximum amount of HDD storage that can be allocated from the resource pool by all users of the tenant combined being set to the value specified. This value should be an integer and in bytes.

    • max_hdd_per_app: <max_app_hdd> - Utilizing this parameter within the dictionary results in the maximum amount of HDD storage that can be allocated from the resource pool resource pool during app creation by each tenant user being set to the value specified. This value should be an integer and in bytes.

    • max_ssd_per_tenant: <max_tenant_hdd> - Utilizing this parameter within the dictionary results in the maximum amount of SSD storage that can be allocated from the resource pool by all users of the tenant combined being set to the value specified. This value should be an integer and in bytes.

    • max_ssd_per_app: <max_app_hdd> - Utilizing this parameter within the dictionary results in the maximum amount of SSD storage that can be allocated from the resource pool resource pool during app creation by each tenant user being set to the value specified. This value should be an integer and in bytes.

    • max_gpu_per_tenant: <max_tenant_gpus> - Utilizing this parameter within the dictionary results in the maximum number of gpus that can be allocated from the resource pool by all users of the tenant combined being set to the integer specified.

    • max_gpu_per_app: <max_app_gpus> - Utilizing this parameter within the dictionary results in the maximum number of gpus that can be allocated from the resource pool resource pool during app creation by each tenant user being set to the integer specified.

Note

To turn off limits for a particular resource type, specify ‘NONE’ instead of a limit amount.

Port: RCM Port (default value is 29442)

Headers:

  • Authorization: <auth_token> : Authorization token to identify which user is sending the request. The token can be acquired from the login API.

Success Response Code: 200

Error Response Code: 500 (Internal Server Error), 404 (Not Found Error), 401 (Unauthorized Error), 400 (Invalid API Usage Error)

Example Response:

Output
{
   "message":"Successfully updated rpool limits for tenant 'Administrators'"
}