Chassis Partition - Tenant Lifecycle¶
Overview¶
Tenancy is required to deploy any BIG-IP resources. Tenant lifecycle can be fully managed via the CLI using the tenants command in config mode.
When configuring HA between two VELOS chassis, there is no HA relationship across chassis for the system controllers or chassis partitions. All high availability (HA) is configured at the tenant level, similar to how HA is configured for vCMP guests in VIPRION.
Prerequisites¶
Before you can create a new tenant on a chassis partition, refer to the Chassis Partition - Initial Networking Setup workflow.
Get Authentication Token¶
F5 disables basic authentication for HTTP/HTTPS requests to the VELOS API by default for security enhancement. You can make HTTP/HTTPS requests to the VELOS API while keeping basic authentication disabled by sending the requests to the chassis partition and by including a valid chassis partition authentication token in the X-Auth-Token header.
Whenever you perform an authenticated login to the chassis partition, and request a token using the Auth Token, you receive an access token. Use it to send HTTP/HTTPS requests to a chassis partition.
Request a new token from the chassis partition using an authenticated login. Using your username and password, log in to the chassis partition.
GET: https://<chassis-partition-ip>:8888/restconf/data/openconfig-system:system/aaa
The value set in the X-Auth-Token in the response Headers is the access token value to use in subsequent requests header along with the application/yang-data+json Content-Type.
- Content-Type: application/yang-data+json
- X-Auth-Token: {{ X-Auth-Token }}
Load Tenant Images¶
Before creating any new tenant you should ensure you have the proper BIG-IP images loaded onto the chassis partition. You can query the chassis partition to see what images are currently available on the system:
GET: https://<chassis-partition-ip>:8888/restconf/data/f5-tenant-images:images
Import the desired image into the chassis partition using the path /var/import/staging.
You will need to import form a remote HTTPS server. There is an insecure option if you don’t want to use certificate-based authentication to the remote HTTPS server.
POST: https://<chassis-system-controller-ip>:8888/api/data/f5-utils-file-transfer:file/import
{
"input": [
{
"remote-host": "<remote-https-server-ip>",
"remote-file": "BIGIP-14.1.4-0.0.9.ALL-VELOS.qcow2.zip.bundle",
"local-file": "IMAGES",
"insecure": ""
}
]
}
The following is the response JSON from the POST method:
{
"f5-utils-file-transfer:output": {
"result": "File transfer is initiated.(/var/F5/partition/IMAGES/BIGIP-14.1.4-0.0.9.ALL-VELOS.qcow2.zip.bundle)"
}
}
Create Tenant¶
A tenant called tenant1 will be created. It will be assigned an out-of-band management IP address, mask and gateway, along with an BIG-IP version that must be loaded before the tenant can be created.
POST: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants
{
"tenant": [
{
"name": "tenant1",
"config": {
"image": "BIGIP-14.1.4-0.0.9.ALL-VELOS.qcow2.zip.bundle",
"nodes": [
1
],
"mgmt-ip": "<chassis-tenant1-ip>",
"gateway": "<out-of-band-default-gw>",
"prefix-length": 24,
"vlans": [
444,
500,
555
],
"vcpu-cores-per-node": 2,
"memory": 7680,
"cryptos": "enabled",
"running-state": "configured"
}
}
]
}
Changing Tenant Running State¶
To deploy the tenant, change the tenant running state to deployed:
PATCH: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants/tenant=tenant1/config/running-state
{
"running-state": "deployed"
}
Displaying Tenant Status¶
This will display the tenant created configuration and state:
GET: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants/tenant=tenant1/config
Resizing a Tenant within a Blade¶
Expanding a tenant on the same blade via the API follows the same workflows as the GUI. You must first put the tenant in a provisioned state, and then make configuration changes, and then change back to deployed state.
First get the current tenant status via the API and note the current CPU Allocation. The tenant in the example below is currently configured to run on slot1 (node) and has 2 vCPU’s and 7680 of memory per slot:
GET: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants/tenant=tenant1/config
The following is the response JSON from the GET method:
{
"f5-tenants:config": {
"name": "tenant1",
"type": "BIG-IP",
"image": "BIGIP-14.1.4-0.0.9.ALL-VELOS.qcow2.zip.bundle",
"nodes": [
1
],
"mgmt-ip": "<chassis-tenant1-ip>",
"prefix-length": 24,
"gateway": "10.255.0.1",
"vlans": [
444,
500,
555
],
"cryptos": "enabled",
"vcpu-cores-per-node": "2",
"memory": "7680",
"running-state": "deployed",
"appliance-mode": {
"enabled": false
}
}
}
If you attempt to change the tenant configuration while it is in the deployed state it will fail with an error like the one below notifying you that config changes when in the deployed state is not allowed:
{
"errors": {
"error": [
{
"error-message": "/tenants/tenant{tenant1}/config/vcpu-cores-per-node (value \"4\"): cannot change vcpu-cores-per-node when tenant is in deployed state",
"error-path": "/f5-tenants:tenants/tenant=tenant1/config/vcpu-cores-per-node",
"error-tag": "invalid-value",
"error-type": "application"
}
]
}
}
The workflow to change the tenant configuration is to first change the tenant state to be provisioned or configured then make the configuration change. Use the following API PATCH call to move the tenant to the provisioned state:
PATH: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants/tenant=tenant1/config/running-state
{
"running-state": "provisioned"
}
Next issue the GET command above to obtain the tenant status and note that its running state has changed to provisioned:
GET: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants/tenant=tenant1/config
The following is the response JSON from the GET method:
...
"cryptos": "enabled",
"vcpu-cores-per-node": "2",
"memory": "7680",
"running-state": "provisioned",
"appliance-mode": {
"enabled": false
...
Send a PATCH API command to change the CPU and memory configuration so the tenant can expand from 2 to 4 vCPU’s and from 7680 to 14848 GB of memory. It’s important to change both the CPU and memory allocation when expanding the tenant.
PATCH: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants/tenant=tenant1/config/vcpu-cores-per-node
{
"vcpu-cores-per-node": 4,
"memory": 14848
}
Finally change the tenant status back to deployed and then check the status again to confirm the change. The tenant should boot up with the expanded memory and CPU.
PATCH: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants/tenant=tenant1/config/running-state
{
"running-state": "deployed"
}
Resizing a Tenant across Blade¶
VELOS tenants can be configured to expand across multiple blades.
The workflow to change the tenant configuration is to first change the tenant state to be provisioned or configured then make the configuration change. Use the following API PATCH call to move the tenant to the provisioned state:
PATCH: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants/tenant=tenant1/config/running-state
{
"running-state": "provisioned"
}
Change the Allowed Slots so that both 1 and 2 are now used. Also change the tenant status back to deployed and then check the status again to confirm the change. The tenant should boot up with the expanded memory and CPU.
PATCH: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants/tenant=tenant1/config/vcpu-cores-per-node
{
"vcpu-cores-per-node": 6,
"memory": 22016,
"nodes": [
1,
2
],
"running-state": "deployed"
}
Delete Tenant¶
In case you need to delete a chassis partition, here is an example:
DELETE: https://<chassis-partition-ip>:8888/restconf/data/f5-tenants:tenants/tenant=tenant1