4. Workload Manager API/CLI Documentation

4.1. Introduction

OpenStack API Access endpoints
Service Service Endpoint
S3 http://192.168.1.54:3333
Identity http://192.168.1.54:5000/v2.0
Object Store http://192.168.1.54:8080/v1/AUTH_c82f6beeb0a9459bbab0b72dcba637d2
EC2 http://192.168.1.54:8773/services/Cloud
Compute http://192.168.1.54:8774/v2/c82f6beeb0a9459bbab0b72dcba637d2
Computev3 http://192.168.1.54:8774/v3
Volume http://192.168.1.54:8776/v1/c82f6beeb0a9459bbab0b72dcba637d2
Volumev2 http://192.168.1.54:8776/v2/c82f6beeb0a9459bbab0b72dcba637d2
Image http://192.168.1.54:9292
Workloads http://192.168.1.123:8780/v1/c82f6beeb0a9459bbab0b72dcba637d2

Trilio Data’s OpenStack Backup and Recovery Offering (“TrilioVault”) is implemented as a native OpenStack Service called Workload Manager. Like other services in OpenStack, workload manager has two components: workloadmgr service and workloadmgr cli. The Command Line Interface (“CLI”) is a thin Python wrapper around the workloadmgr RESTful API. This service is responsible for creating backup jobs, scheduling backup jobs for execution and uploading VM images to backup media and restoring backup images.

During workloadmgr configuration, workloadmanager endpoints are registered with the Keystone OpenStack Service. These endpoints are discovered by workloadmgr cli and other OpenStack applications and invoke RESTful API.

4.2. Architecture

Workload Manager is built on a shared-nothing, messaging-based architecture. All the major components can be run on multiple virtual machines. This means that most component-to-component communication must go via message queue. To avoid blocking each component while waiting for a response, we use deferred objects, with a callback that gets triggered when a response is received. Workload Manager uses a SQL-based central database that is deployed on the workload manager controller node and other nodes in the TrilioVault deployments uses the database over sql connection. The amount and depth of the TrilioVault data fits into a SQL database quite well.

4.2.1. Main Components

OpenStack API Access endpoints!
Component Description
Web/Horizon Dashboard Potential external component that talks to the api. Api component that receives
http requests converts commands and communicates with other components via the queue or http
(in the case of objectstore).  
Auth Manager/Keystone Component responsible for users/projects/and roles. Can backend to a DB or LDAP. This is not a separate binary, but rather a Python class that is used by most components in the system.
objectstore http server that replicates the s3 api and allows storage and retrieval of backup images.
NFS NFS backup for storing and retrieving backup images.
Scheduler Decides which TrilioVault executes the next backup job.
Workload Manages communication with hypervisor and virtual machines.

4.3. RESTful API

workloadmgr API and CLI are designed to be very similar to other OpenStack services such as nova, cinder etc. which means you can source tenant/admin credentials rc file in shell and invoke workloadmgr cli. workloadmgr cli also supports –debug option that provides the RESTful api call sequence so you can understand the request and response payloads associated with each CLI. Instead of duplicating RESTful payload for each call in this documentation, we encourage you to examine the RESTful API call sequence –debug option. For example, listing workloads payload is shown below:

[centos@centos7 ~]$ workloadmgr --debug workload-list

REQ: curl -i http://192.168.1.104:5000/v2.0/tokens -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-workloadmgrclient" -d '{"auth": {"tenantName": "demo", "passwordCredentials": {"username": "demo", "password": "project1"}}}'

RESP: [200] {'Content-Length': '3606', 'Vary': 'X-Auth-Token', 'Keep-Alive': 'timeout=5, max=100', 'Server': 'Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5', 'Connection': 'Keep-Alive', 'Date': 'Tue, 03 Oct 2017 00:27:38 GMT', 'Content-Type': 'application/json', 'x-openstack-request-id': 'req-241493fe-c3ba-4746-86ca-a4acba2cadd7'}
RESP BODY: {"access": {"token": {"issued_at": "2017-10-03T00:27:44.373169", "expires": "2017-10-03T01:27:44Z", "id": "1b961707c9a94ef596eaeb14896c38d1", "tenant": {"description": "", "enabled": true, "id": "8cc66459d2144d359f88b173557593ab", "name": "demo"}, "audit_ids": ["DjUCzen8RTmRXWRzfyYxtg"]}, "serviceCatalog": [{"endpoints": [{"adminURL": "http://192.168.1.104:8774/v2.1/8cc66459d2144d359f88b173557593ab", "region": "RegionOne", "internalURL": "http://192.168.1.104:8774/v2.1/8cc66459d2144d359f88b173557593ab", "id": "a0320e3c863d41e4b1940a8c5f93e07c", "publicURL": "http://192.168.1.104:8774/v2.1/8cc66459d2144d359f88b173557593ab"}], "endpoints_links": [], "type": "compute", "name": "nova"}, {"endpoints": [{"adminURL": "http://192.168.1.104:9696/", "region": "RegionOne", "internalURL": "http://192.168.1.104:9696/", "id": "06ae90d872944e35a2f919bff19b2bcd", "publicURL": "http://192.168.1.104:9696/"}], "endpoints_links": [], "type": "network", "name": "neutron"}, {"endpoints": [{"adminURL": "http://192.168.1.104:8776/v2/8cc66459d2144d359f88b173557593ab", "region": "RegionOne", "internalURL": "http://192.168.1.104:8776/v2/8cc66459d2144d359f88b173557593ab", "id": "40b486f68d67460098669b4946442553", "publicURL": "http://192.168.1.104:8776/v2/8cc66459d2144d359f88b173557593ab"}], "endpoints_links": [], "type": "volumev2", "name": "cinderv2"}, {"endpoints": [{"adminURL": "http://192.168.1.104:9292", "region": "RegionOne", "internalURL": "http://192.168.1.104:9292", "id": "7c461d7deefd47df8b7383cb5d3543a6", "publicURL": "http://192.168.1.104:9292"}], "endpoints_links": [], "type": "image", "name": "glance"}, {"endpoints": [{"adminURL": "http://192.168.1.104:8774/v2/8cc66459d2144d359f88b173557593ab", "region": "RegionOne", "internalURL": "http://192.168.1.104:8774/v2/8cc66459d2144d359f88b173557593ab", "id": "7f0aa414af5b43c388cabb7dd793a6b4", "publicURL": "http://192.168.1.104:8774/v2/8cc66459d2144d359f88b173557593ab"}], "endpoints_links": [], "type": "compute_legacy", "name": "nova_legacy"}, {"endpoints": [{"adminURL": "http://192.168.1.104:8776/v1/8cc66459d2144d359f88b173557593ab", "region": "RegionOne", "internalURL": "http://192.168.1.104:8776/v1/8cc66459d2144d359f88b173557593ab", "id": "4a4877bd56ad48f8a0d3b88c2c2812ae", "publicURL": "http://192.168.1.104:8776/v1/8cc66459d2144d359f88b173557593ab"}], "endpoints_links": [], "type": "volume", "name": "cinder"}, {"endpoints": [{"adminURL": "http://192.168.1.104:8773/", "region": "RegionOne", "internalURL": "http://192.168.1.104:8773/", "id": "55b2a0659f8f42b1972053f69a1e7856", "publicURL": "http://192.168.1.104:8773/"}], "endpoints_links": [], "type": "ec2", "name": "ec2"}, {"endpoints": [{"adminURL": "http://192.168.1.64:8780/v1/8cc66459d2144d359f88b173557593ab", "region": "RegionOne", "internalURL": "http://192.168.1.64:8780/v1/8cc66459d2144d359f88b173557593ab", "id": "19644a9628da4773942613999b5de67d", "publicURL": "http://192.168.1.64:8780/v1/8cc66459d2144d359f88b173557593ab"}], "endpoints_links": [], "type": "workloads", "name": "TrilioVaultWLM"}, {"endpoints": [{"adminURL": "http://192.168.1.104:35357/v2.0", "region": "RegionOne", "internalURL": "http://192.168.1.104:5000/v2.0", "id": "87fa0e616328469da755204dc1ef2920", "publicURL": "http://192.168.1.104:5000/v2.0"}], "endpoints_links": [], "type": "identity", "name": "keystone"}], "user": {"username": "demo", "roles_links": [], "id": "29d7ee699b164b0aa40df38e04ea9670", "roles": [{"name": "Member"}, {"name": "anotherrole"}], "name": "demo"}, "metadata": {"is_admin": 0, "roles": ["159f2e2a3a9740879633db37a242f3cd", "ab9c637b19a6488fa835e1152fe394df"]}}}

REQ: curl -i http://192.168.1.64:8780/v1/8cc66459d2144d359f88b173557593ab/workloads -X GET -H "X-Auth-Project-Id: demo" -H "User-Agent: python-workloadmgrclient" -H "Accept: application/json" -H "X-Auth-Token: 1b961707c9a94ef596eaeb14896c38d1"

RESP: [200] {'Date': 'Tue, 03 Oct 2017 00:27:44 GMT', 'X-Compute-Request-Id': 'req-00d94bb2-7553-4fb3-93e0-a8b1b22369e4', 'Connection': 'keep-alive', 'Content-Type': 'application/json', 'Content-Length': '1354'}
RESP BODY: {"workloads": [{"status": "available", "description": "no-description", "links": [{"href": "http://192.168.1.64:8780/v1/8cc66459d2144d359f88b173557593ab/workloads/fd14c357-4f96-427e-a4a9-512993030d9f", "rel": "self"}, {"href": "http://192.168.1.64:8780/8cc66459d2144d359f88b173557593ab/workloads/fd14c357-4f96-427e-a4a9-512993030d9f", "rel": "bookmark"}], "workload_type_id": "f82ce76f-17fe-438b-aa37-7a023058e50d", "updated_at": "2017-09-27T01:31:24.000000", "id": "fd14c357-4f96-427e-a4a9-512993030d9f", "user_id": "29d7ee699b164b0aa40df38e04ea9670", "name": "vm2", "created_at": "2017-09-26T01:15:03.000000", "snapshots_info": "", "project_id": "8cc66459d2144d359f88b173557593ab"}, {"status": "available", "description": "no-description", "links": [{"href": "http://192.168.1.64:8780/v1/8cc66459d2144d359f88b173557593ab/workloads/ee290e62-8045-4a07-a7de-ca8fe91321a1", "rel": "self"}, {"href": "http://192.168.1.64:8780/8cc66459d2144d359f88b173557593ab/workloads/ee290e62-8045-4a07-a7de-ca8fe91321a1", "rel": "bookmark"}], "workload_type_id": "f82ce76f-17fe-438b-aa37-7a023058e50d", "updated_at": "2017-09-26T01:16:04.000000", "id": "ee290e62-8045-4a07-a7de-ca8fe91321a1", "user_id": "29d7ee699b164b0aa40df38e04ea9670", "name": "vm", "created_at": "2017-09-23T11:34:03.000000", "snapshots_info": "", "project_id": "8cc66459d2144d359f88b173557593ab"}]}

+--------------------------------------+------+----------------------------------+--------------------------------------+-----------+----------------------------+
|                  ID                  | Name |            Project_ID            |           Workload_Type_ID           |   Status  |         Created_at         |
+--------------------------------------+------+----------------------------------+--------------------------------------+-----------+----------------------------+
| ee290e62-8045-4a07-a7de-ca8fe91321a1 |  vm  | 8cc66459d2144d359f88b173557593ab | f82ce76f-17fe-438b-aa37-7a023058e50d | available | 2017-09-23T11:34:03.000000 |
| fd14c357-4f96-427e-a4a9-512993030d9f | vm2  | 8cc66459d2144d359f88b173557593ab | f82ce76f-17fe-438b-aa37-7a023058e50d | available | 2017-09-26T01:15:03.000000 |
+--------------------------------------+------+----------------------------------+--------------------------------------+-----------+----------------------------+

4.4. Command Line Interface

workloadmgr utility is workloadmgr client that can be downloaded from a TrilioVault appliance as a Python pip module. It is a thin-client that wraps the Workload Manager RESTful API. There is almost a one-to-one mapping from workloadmgr command to the REST API. This section describes Workload Manager commands, its usage and the arguments to each command.

A typical workloadmgr command line is:

workloadmgr <subcommand> <arguments>

The following sections describe each subcommand in detail.

4.4.1. Workload Types

TrilioVault’s workloadmgr supports the concept called workload types. A workload is a group of related VMs and their associated resources that need to be managed as one unit. The data consistency and data integrity of the underlying application(s) depend on how these VMs are backed up. Workload types define predefined mechanisms to perform consistent snapshots of workloads. TrilioVault comes with two predefined workload types:

Workload Types Description
Serial Serial workloads performs VM snapshots in the workload in the order in which they appear. If there is data dependency between VMs in a workload this is the workload type one must choose. Only snapshot operations are serialized. Data upload is performed in parallel.
Parallel Parallel workload type performs VM snapshots in no specific order. As in Serial workload, all data uploads are performed in parallel. If VMs in a workload do not have data dependency, this is the workload type one should choose

4.4.1.1. Workload Type CLIs

4.4.1.1.1. workload-type-show

Usage

workloadmgr workload-type-show <workload-type-id>

Arguments

<workload-type-id>   ID of the workload type

Description

Shows the detailed description of the workload type.

4.4.1.1.2. workload-type-list

Usage

workloadmgr workload-type-list

Arguments

None

Description

Lists registered workload types

4.4.2. Workloads

4.4.2.1. Workload CLIs

A workload is a collection of VMs that are managed together as one entity for backup and recovery purposes. Each workload includes a workload type and a job scheduler defines how frequently the backup need to be performed and how many backups need to be retained on the backup media.

4.4.2.1.1. workload-create

Usage

workloadmgr workload-create [--display-name <display-name>]
                            [--display-description <display-description>]
                            --workload-type-id <workload-type-id>
                            --source-platform <source-platform>
                            [--instance <instance-id=instance-uuid>]
                            [--jobschedule <key=key-name>]
                            [--metadata <key=key-name>]
                            [--workloadids <workloadid>]

Creates a workload.

Arguments

--display-name <display-name> Optional workload name. (Default=None)

--display-description <display-description> Optional workload description. (Default=None)

--workload-type-id <workload-type-id> Workload Type ID is required
--source-platform <source-platform> Workload source platform is required. Supported platforms are 'openstack' and 'vmware'
--instance <instance-id=instance-uuid> Specify an instance to include in the workload. Specify option multiple times to include multiple instances. instance-id: include the instance with this UUID
--jobschedule <key=key-name> Specify following key value pairs for jobschedule Specify option multiple times to include multiple keys. 'start_date' : '06/05/2014' 'end_date' : '07/15/2014' 'start_time' : '2:30 PM' 'interval' : '1 hr' 'snapshots_to_retain' : '2'
--metadata <key=key-name> Specify a key value pairs to include in the workload_type metadata Specify option multiple times to include multiple keys. key=value
--workloadids <workloadid>

Description

Creates a new workload (a backup group) that includes one more VMs identified by their GUID.

The other workload APIs including workload-list, workload-show and workload-delete are self-explanatory and do not require further explanation.

4.4.2.1.2. workload-unlock

Usage

workloadmgr workload-unlock <workload_id>

Unlocks a workload.

Arguments

<workload_id> ID of the workload to unlock
4.4.2.1.3. workload-list

Usage

workloadmgr workload-list

Lists all workloads of current project. Admin user can list the workloads from all the tenants. Also, there is a provision for listing the workloads per nfs share.

Optional Arguments:

--all {True,False}    List all workloads of all the projects(valid for admin user only)
--nfsshare <nfsshare> List all workloads of nfsshare (valid for admin user only)
4.4.2.1.4. workload-delete

Usage

workloadmgr workload-delete <workload_id>

Deletes a workload.

Arguments

<workload_id> ID/name of the workload to be deleted
4.4.2.1.5. workload-get-auditlog

Usage

workloadmgr workload-get-auditlog [--time_in_minutes <time_in_minutes>][--time_from <time_from>][--time_to <time_to>]

Gets auditlog of workload manager.

Arguments

--time_in_minutes <time_in_minutes>  time in minutes(default is 24 hrs.)
--time_from <time_from> From date time in format 'MM-DD-YYYY'
--time_to <time_to>   To date time in format 'MM-DD-YYYY'(default is current day)
4.4.2.1.6. workload-get-importworkloads-list

Usage

workloadmgr workload-get-importworkloads-list

Get list of workloads to be imported.

4.4.2.1.7. workload-get-nodes

Usage

workloadmgr workload-get-nodes

Get all the nodes of a workload manager.

4.4.2.1.8. workload-get-recentactivities

Usage

workloadmgr workload-get-recentactivities [--time_in_minutes <time_in_minutes>]

Get recentactivities of workload manager.

Arguments

--time_in_minutes <time_in_minutes>  time in minutes
4.4.2.1.9. workload-get-storage-usage

Usage

workloadmgr workload-get-storage-usage

Get total storage used by workload manager per nfs share.

4.4.2.1.10. workload-importworkloads

Usage

workloadmgr workload-importworkloads [--workloadids <workloadid>][--upgrade <upgrade>]

Import all workload records from backup store.

Arguments

--workloadids <workloadid> Specify workload ids to import only specified workloads --workloadids <workloadid>
--upgrade <upgrade>   Specify True or False. Default is True
4.4.2.1.11. workload-get-orphaned-workloads-list

Usage

workloadmgr workload-get-orphaned-workloads-list [--migrate_cloud {True,False}] [--generate_yaml {True,False}]

Discovers the list of workloads that does not belong to current cloud. This API is useful to implement disaster recovery use case where user has setup two clouds and the backup repository is replicated between two clouds. In case the primary cloud goes down and wants to bring the applications on DR cloud, user can use this command to discover all workloads.

Arguments

--migrate_cloud {True,False} True means discover workloads that don’t belong to current cloud.
--generate_yaml {True,False} True means generate a YAML file that can be used as input to workload-reassign-workloads command.
4.4.2.1.12. workload-reassign-workloads

Usage

workloadmgr workload-reassign-workloads [--old_tenant_ids <old_tenant_id>]
                                        [--new_tenant_id <new_tenant_id>]
                                        [--workload_ids <workload_id>]
                                        [--user_id <user_id>]
                                        [--migrate_cloud {True,False}]
                                        [--map_file <map_file>]

Assign workload(s) to a new tenant/user.

Optional arguments:

--old_tenant_ids <old_tenant_id>
                      Specify old tenant ids from which workloads need to
                      reassign to new tenant. --old_tenant_ids
                      <old_tenant_id> --old_tenant_ids <old_tenant_id>
--new_tenant_id <new_tenant_id>
                      Specify new tenant id to which workloads need to
                      reassign from old tenant. --new_tenant_id
                      <new_tenant_id>
--workload_ids <workload_id>
                      Specify workload_ids which need to reassign to new
                      tenant. If not provided then all the workloads from
                      old tenant will get reassigned to new tenant.
                      --workload_ids <workload_id> --workload_ids
                      <workload_id>
--user_id <user_id>   Specify user id to which workloads need to reassign
                      from old tenant. --user_id <user_id>
--migrate_cloud {True,False}
                      Set to True if want to reassign workloads from other
                      clouds as well. Default if False
--map_file <map_file>
                      Provide list of old worloads mapped to new tenants.
                      Format for this file is YAML.

Sample YAML file looks as follows:

reassign_mappings:
               - old_tenant_ids: [] #user can provide list of old_tenant_ids or workload_ids
                 new_tenant_id: new_tenant_id
                 user_id: user_id
                 workload_ids: [] #user can provide list of old_tenant_ids or workload_ids
                 migrate_cloud: {True,False} #Set to True if want to reassign workloads from other
                                             # clouds as well. Default is False

               - old_tenant_ids: [] #user can provide list of old_tenant_ids or workload_ids
                 new_tenant_id: new_tenant_id
                 user_id: user_id
                 workload_ids: [] #user can provide list of old_tenant_ids or workload_ids
                 migrate_cloud: {True,False} #Set to True if want to reassign workloads from other
                                             # clouds as well. Default is False
4.4.2.1.13. workload-modify

Usage

workloadmgr  workload-modify [--display-name <display-name>]
                             [--display-description <display-description>]
                             [--instance <instance-id=instance-uuid>]
                             [--jobschedule <key=key-name>]
                             [--metadata <key=key-name>]
                             <workload_id>

Modify a workload.

Arguments

Required:

<workload_id>         ID of the workload.

Optional:

--display-name <display-name>
                      Optional workload name. (Default=None)
--display-description <display-description>
                      Optional workload description. (Default=None)
--instance <instance-id=instance-uuid>
                      Specify an instance to include in the workload.
                      Specify option multiple times to include multiple
                      instances. instance-id: include the instance with this
                      UUID
--jobschedule <key=key-name>
                      Specify following key value pairs for jobschedule
                      Specify option multiple times to include multiple
                      keys. 'start_date' : '06/05/2014' 'end_date' :
                      '07/15/2014' 'start_time' : '2:30 PM' 'interval' : '1
                      hr' 'retention_policy_type' : 'Number of Snapshots to
                      Keep' or 'Number of days to retain Snapshots'
                      'retention_policy_value' : '30'
--metadata <key=key-name>
                      Specify a key value pairs to include in the
                      workload_type metadata Specify option multiple times
                      to include multiple keys. key=value
4.4.2.1.14. workload-remove-node

Usage

workloadmgr workload-remove-node <ip>

Remove workload node by ipaddress / hostname. To remove additional node, run remove-node command & then delete the vm instance.

Arguments

<ip>  IP or hostname of node to remove
4.4.2.1.15. workload-reset

Usage

workloadmgr workload-reset <workload_id>

Resets a workload. TrilioVault uses storage based snapshots for calculating backup images of application resources. For cinder volumes, it uses cinder snapshots and for ceph based nova backends, it uses ceph snapshots for calculating the backup images. Depending the state of the workload backup operation, each of these resources may have one or more snapshots outstanding. Workload-reset deletes all outstanding snapshots on all resources of the application. Workload-reset is useful if you want to decommission the application, but you still want to keep all the backups of the application.

Note

It is highly recommended to perform workload-reset before deleting any application resources from OpenStack.

Arguments

<workload_id>  ID of the workload to reset
4.4.2.1.16. workload-show

Usage

workloadmgr workload-show <workload_id> [--verbose <verbose>]

Show details about a workload.

Arguments

Required:

<workload_id>  ID/name of the workload

Optional:

--verbose <verbose>  Get detailed information of workload with specifying –verbose

4.4.2.2. Snapshot CLIs

Snapshot or backups are created from workloads. Snapshots can be created on an on-demand basis or by the underlying job scheduler. Each snapshot resource is created by CLI called workload-snapshot.

4.4.2.2.1. workload-snapshot

Usage

workloadmgr workload-snapshot [--full]
                              [--display-name <display-name>]
                              [--display-description <display-description>]
                              <workload_id>

Creates an on demand snapshot for a given workload.

Arguments

--full Specify if a full snapshot is required. By default workloadmgr makes best effort to perform incremental snapshots.
--display-name <display-name> Optional snapshot name. (Default=None)
--display-description <display-description> Optional snapshot description. (Default=None)

Description

Once a snapshot resource is created, Workload Manager supports snapshot-list, snapshot-show and snapshot-delete operations on the snapshot resource; a typical usage pattern of any RESTful resource.

4.4.2.2.2. snapshot-mount

Usage

workloadmgr snapshot-mount [--options <options>] <snapshot_id>

Mounts a workload snapshot for exploring individual files.

Arguments

<snapshot_id>   ID of the workload snapshot to mount.
--options <options>  Mount options. (Default={})

Description

snapshot-mount mounts all volumes/partitions that are present in all VMs and provide an URL for end use to explore the file system contents on each of these volumes partitions in a file manager view. User can download and view individual files. A user cannot modify any contents in the snapshot. Current implementation mounts all Linux file systems and NTFS file system mounted on regular partitions. Dynamic volumes are supported in subsequent releases. Snapshot cannot be mounted multiple times simultaneously.

4.4.2.2.3. snapshot-dismount

Usage

workloadmgr snapshot-dismount <snapshot_id>

Dismount a mounted snapshot. Workloadmgr frees up all mount points and the URL is not accessible any more.

Arguments

<snapshot_id>  ID of the workload snapshot to dismount.

4.4.2.3. Restore CLI

A snapshot can be restored to the target environment. Workloadmgr supports three flavors of restore operation: Selective Restore, In place Restore and One-click Restore. Selective Restore gives the user more control over how the snapshot is restored; whereas, One-click Restore provides a simple way to restore the snapshot in its entirety on the same environment where the snapshot was taken.

4.4.2.3.1. snapshot-selective-restore

Usage

workloadmgr snapshot-selective-restore [--display-name <display-name>]
                                       [--display-description <display-description>]
                                       [--filename <filename>] <snapshot_id>

Selective Restore workload snapshot.

Arguments

<snapshot_id> ID of the workload snapshot to restore.

--display-name <display-name> Optional name for the restore. (Default=None)

--display-description <display-description> Optional description for restore. (Default=None)

--filename <filename> File name in folder /opt/stack/python-workloadmgrclient/input-files (Default=restore.json). Replace values into sample files

Once a snapshot is restored, a restored resource can be managed using standard RESTful verbs like restore-list, restore-show and restore-delete. Restore resource captures all the resources that were created as part of the restore operation. However, restore-delete does not delete any of these restored resources. It merely deletes the restore object in the SQL database.

4.4.2.3.2. snapshot-list

Usage

workloadmgr snapshot-list [--workload_id <workload_id>]
                          [--tvault_node <host>]

List all the workload snapshots. Workload snapshots can be filtered based on date. All tenant snapshots can be listed by admin user using –all option.

Optional Arguments:

--workload_id <workload_id> Filter results by workload_id

--tvault_node <host> List all the snapshot operations scheduled on a tvault node(Default=None)
--date_from <date_from> From date in format 'YYYY-MM-DDTHH:MM:SS' eg 2016-10-10T00:00:00
--date_to <date_to>   To date in format 'YYYY-MM-DDTHH:MM:SS'(defult is current day)
--all {True,False}    List all snapshots of all the projects(valid for admin
                     user only)
4.4.2.3.3. snapshot-cancel

Usage

workloadmgr snapshot-cancel <snapshot_id>

Cancel a snapshot that is running. If the snapshot operation is in the middle of the data transfer of a resource, it waits for the data transfer operation is complete before terminating the snapshot operation.

Arguments

<snapshot_id>  ID of the snapshot to cancel
4.4.2.3.4. snapshot-delete

Usage

workloadmgr snapshot-delete <snapshot_id>

Removes a snapshot.

Arguments

<snapshot_id>  ID/name of the snapshot to delete
4.4.2.3.5. snapshot-oneclick-restore

Usage

workloadmgr snapshot-oneclick-restore [--display-name <display-name>]
                                      [--display-description <display-description>]
                                      [--options <options>]<snapshot_id>

Restore a workload snapshot.

Arguments

Required:

<snapshot_id>  ID of the snapshot to restore

Optional:

--display-name <display-name> Optional name for the restore. (Default=None)

--display-description <display-description> Optional description for restore. (Default=None)

--options <options>   Restore options. (Default={'openstack': {}, 'type':'vmware', 'oneclickrestore': True, 'vmware':{}})
4.4.2.3.6. snapshot-mounted-list

Usage

workloadmgr snapshot-mounted-list [--workloadid <workloadid>]

List of all mounted snapshots.

Arguments

--workloadid <workloadid> Workload id (Default=None)
4.4.2.3.7. snapshot-show

Usage

workloadmgr snapshot-show [--output <output>] <snapshot_id>

Show details about a workload snapshot.

Arguments Required:

<snapshot_id>      ID/name of the workload snapshot

Optional:

--output <output>  Option to get additional snapshot details,

--output metadata for snapshot metadata,
-–output networks for snapshot vms networks,
-–output disks for snapshot vms disks

4.4.2.4. Scheduler CLIs

Scheduler is responsible for taking periodic snapshots of vm’s belong to a workload.

4.4.2.4.1. enable-scheduler

Usage

workloadmgr enable-scheduler <workload_id>

Enables a scheduler

Arguments

<workload_id> ID of the workload whose scheduler is to be enabled.
              –workloadids can be specified multiple times to specify multiple workloads.
4.4.2.4.2. disable-scheduler

Usage

workloadmgr disable-scheduler <workload_id>

Disables a scheduler

Arguments

<workload_id> ID of the workload whose scheduler is to be disabled.
              –workloadids can be specified multiple times to specify multiple workloads.
4.4.2.4.3. enable-global-job-scheduler

Usage

workloadmgr enable-global-job-scheduler

Enables global job scheduler

4.4.2.4.4. disable-global-job-scheduler

Usage

workloadmgr disable-global-job-scheduler

Disables global job scheduler

4.4.2.4.5. get-global-job-scheduler

Usage

workloadmgr get-global-job-scheduler

Gets global job scheduler status

4.4.2.5. Licensing

Licensing CLIs are responsible for applying license information to the product as well list the applied license.

4.4.2.5.1. license-create

Usage

workloadmgr license-create <license_file>

Creates a license (Admin only)

In case the user has a license.key file, license can be applied by using the following command:

workloadmgr license-create license.key

Arguments

<license_file>  License file that is supplied by TrilioData, Inc
4.4.2.5.2. license-list

Usage

workloadmgr license-list

Lists the license (Admin only).

4.4.2.5.3. license-list

Usage

workloadmgr license-check

Check the license. (Admin only)

4.4.2.6. Restore CLI

Restore commands are responsible for performing restores of workload snapshots.

4.4.2.6.1. restore-list

Usage

workloadmgr restore-list [--snapshot_id <snapshot_id>]

List all the restores.

Arguments .. code:: bash

–snapshot_id <snapshot_id> Filter results by snapshot_id
4.4.2.6.2. restore-show

Usage

workloadmgr restore-show [--output <output>] <restore_id>

Show details about a workload snapshot restore.

Arguments

Required:

<restore_id>       ID/name of the restore

Optional:

--output <output> Option to get additional restore details,

--output metadata for restore metadata

--output networks --output subnets

--output routers –output flavors
4.4.2.6.3. restore-cancel

Usage

workloadmgr restore-cancel <restore_id>

Cancel a restore.

Arguments

<restore_id>  ID of restore to cancel
4.4.2.6.4. restore-delete

Usage

workloadmgr restore-delete <restore_id>

Delete a restore.

Arguments

<restore_id>  ID/name of restore to delete

4.4.2.7. OpenStack Configuration Backup

This section describes CLI to manage OpenStack configuration backup. OpenStack configuration includes all services configuration files, configuration database and any data files associated with each of OpenStack services. This is admin only feature.

4.4.2.7.1. config-backup

Usage

workloadmgr config-backup [--display-name <display-name>]
                          [--display-description <display-description>]

Take backup of OpenStack config.

Optional arguments:

--display-name <display-name>
                      Optional backup name. (Default=Config backup)
--display-description <display-description>
                      Optional backup description. (Default=None)

Take backup of OpenStack config

4.4.2.7.2. config-backup-delete

Usage

workloadmgr config-backup-delete <backup_id>

Delete a config backup.

Positional arguments:

<backup_id>  ID of the backup to delete.
4.4.2.7.3. config-backup-list

Usage

workloadmgr config-backup-list

list all config backups.

4.4.2.7.4. config-backup-show

Usage

workloadmgr config-backup-show <backup_id>

Show config backup.

Positional arguments:

<backup_id>  ID of the bakup to show.
  workloadmgr config-backup-show <backup_id>
4.4.2.7.5. config-workload-configure
workloadmgr config-workload-configure [--jobschedule <key=key-name>]
                                      [--config-file <config_file_path>]
                                      [--authorized-key <authorized_key>]

Configure services to backup and scheduler for OpenStack config workload.

Optional arguments:

--jobschedule <key=key-name>
                      Specify following key value pairs for jobschedule
                      Specify option multiple times to include multiple
                      keys. 'start_time' : '2:30 PM' 'interval' : '1 hr'
                      'retention_policy_value' : '30' , For example
                      --jobschedule enabled=TrueIn order to enable/disable
                      scheduler pass enabled True / enabled False
--config-file <config_file_path>
                      Provide file path(relative or absolute) including file
                      name , This file should contain list of services to
                      backup, their respective config, log folders and root
                      credentials for database. This should be in YAML
                      format. For this you can refer to this template file
                      /usr/lib/python2.7/site-packages/workloadmgrclient
                      /input-files/services_to_backup.yaml:
--authorized-key <authorized_key>
                      Provide file path(relative or absolute) including file
                      name , This private key would be used to connect with
                      controller nodesover the SSH.
4.4.2.7.6. config-workload-scheduler-disable

Usage

workloadmgr config-workload-scheduler-disable

Disable scheduler for config workload.

4.4.2.7.7. config-workload-scheduler-enable

Usage

workloadmgr config-workload-scheduler-enable [--jobschedule <key=key-name>]

Enable/update scheduler for config workload.

Optional arguments:

--jobschedule <key=key-name>
                      Specify following key value pairs for jobschedule
                      Specify option multiple times to include multiple
                      keys. 'start_time' : '2:30 PM' 'interval' : '1 hr'
                      'retention_policy_value' : '30' , For example
                      --jobschedule start_time='2:30 PM' --jobschedule
                      retention_policy_value='30'
4.4.2.7.8. config-workload-show

Usage

workloadmgr config-workload-show

Show config backup workload object

4.4.2.8. Trust CLIs

Trust CLIs are responsible for creating a trust for a user role for it to take a workload snapshot.

4.4.2.8.1. trust-create

Usage

workloadmgr trust-create <role_name>

Creates a trust.

Arguments

<role_name>  name of the role that user wants to be trusted
4.4.2.8.2. trust-show

Usage

workloadmgr trust-show <trust_id>

Show details of a trust.

Arguments

<trust_id>  trust ID
4.4.2.8.3. trust-list

Usage

workloadmgr trust-list

Lists all the trusts.

4.4.2.8.4. trust-delete

Usage

workloadmgr trust-delete <trust_id>

Remove a trust.

Arguments

<trust_id>  trust ID

4.4.2.9. Settings CLIs

Settings CLIs help in creating/changing different TrilioVault settings.

4.4.2.9.1. setting-create

Usage

workloadmgr setting-create [--description <description>]
                           [--category <category>] [--type <type>]
                           [--is-public {True,False}]
                           [--is-hidden {True,False}]
                           [--metadata <key=value>]
                           <name> <vaule>

Creates a setting.

Arguments

Required:

<name>               name of the setting
<value>              Value of the setting

Optional:

 --description <description> Optional description. (Default=None)

--category <category> Optional category. (Default=None)

--type <type>         Optional type of setting. (Default=None)

--is-public {True,False} Make setting accessible to the public.

--is-hidden {True,False} Make setting hidden.

--metadata <key=value>
                      Specify a key value pairs to include in the settings
                      metadata Specify option multiple times to include multiple keys. key=value
4.4.2.9.2. setting-list

Usage

workloadmgr setting-list [--get_hidden {True,False}]

List all the settings.

Arguments

--get_hidden {True,False} show hidden settings
4.4.2.9.3. setting-show

Usage

workloadmgr setting-show [--get_hidden {True,False}] <setting_name>

Show details of a setting.

Arguments

Required:

<setting_name>        name of the setting

Optional:

--get_hidden {True,False} show hidden settings
4.4.2.9.4. setting-update

Usage

workloadmgr setting-update [--description <description>]
                           [--category <category>] [--type <type>]
                           [--is-public {True,False}]
                           [--is-hidden {True,False}]
                           [--metadata <key=value>]
                           <name> <vaule>

Updates a setting.

Arguments

Required:

<name>               name of the setting
<value>              Value of the setting

Optional:

--description <description>
                      Optional description. (Default=None)
--category <category>
                      Optional category. (Default=None)
--type <type>         Optional type of setting. (Default=None)
--is-public {True,False}
                      Make setting accessible to the public.
--is-hidden {True,False}
                      Make setting hidden.
--metadata <key=value>
                      Specify a key value pairs to include in the settings
                      metadata Specify option multiple times to include multiple keys. key=value
4.4.2.9.5. setting-delete

Usage

workloadmgr setting-delete <setting_name>

Remove a setting.

Arguments

<setting_name>  name of setting to delete

4.5. Sample restore.json

{'type': 'openstack',
 'openstack': {
    'instances':
        [
           {
             'id': 'ccf24cd7-43f8-4d8f-8768-227b995cd448', # identifies the instance
             'name': 'restored', # new name for the new instance
             'include': True,    # False if you want to exclude this instance from
             'power': {          # the order in which we need to poweron the vm
                 'sequence': 1,
             },
             # if flavor exists, reuse the flavor or
             # create a new flavor
             'flavor': {         # flavor of the vm. If restore flow finds a flavor that
                 'vcpus': 1,     # matches these attributes, it uses the flavor id.
                 'ram': 2048,       # otherwise it creates new flavor
                 'disk': 10,
                 'ephemeral': True,
                 'swap': 8,
             },
             # First try attaching to the following network.
             # Each network is keyed of the mac address of the original VM.
             # if there is no mention of mac address, then it tries to
             # restore the VM to the original network. Otherwise it
             # tries to find the new network from the networks_mapping
             # stanza. If it can't find a network, restore fails
             'nics': [
             ],
           },
           {
             'id': '1e37e409-dffd-47b1-b9e3-be5806c81e88', # identifies the instance
             'name': 'restored', # new name for the new instance
             'include': True,    # False if you want to exclude this instance from
             'power': {          # the order in which we need to poweron the vm
                 'sequence': 1,
             },
             # if flavor exists, reuse the flavor or
             # create a new flavor
             'flavor': {         # flavor of the vm. If restore flow finds a flavor that
                 'vcpus': 1,     # matches these attributes, it uses the flavor id.
                 'ram': 2048,       # otherwise it creates new flavor
                 'disk': 10,
                 'ephemeral': True,
                 'swap': 8,
             },
             # First try attaching to the following network.
             # Each network is keyed of the mac address of the original VM.
             # if there is no mention of mac address, then it tries to
             # restore the VM to the original network. Otherwise it
             # tries to find the new network from the networks_mapping
             # stanza. If it can't find a network, restore fails
             'nics': [
             ],
           },
           {
             'id': '54ae5237-e2ea-4d03-855c-f7c7ec1cda13', # identifies the instance
             'name': 'restored', # new name for the new instance
             'include': True,    # False if you want to exclude this instance from
             'power': {          # the order in which we need to poweron the vm
                 'sequence': 1,
             },
             # if flavor exists, reuse the flavor or
             # create a new flavor
             'flavor': {         # flavor of the vm. If restore flow finds a flavor that
                 'vcpus': 1,     # matches these attributes, it uses the flavor id.
                 'ram': 2048,       # otherwise it creates new flavor
                 'disk': 10,
                 'ephemeral': True,
                 'swap': 8,
             },
             # First try attaching to the following network.
             # Each network is keyed of the mac address of the original VM.
             # if there is no mention of mac address, then it tries to
             # restore the VM to the original network. Otherwise it
             # tries to find the new network from the networks_mapping
             # stanza. If it can't find a network, restore fails
             'nics': [
             ],
           },
        ],
    'networks_mapping': {
        # We only need private networking
        # workload manager need not do anything mappings to
        # router and perhaps to mapping to public networking
        # if the mapping is not found, we fail the restore.
        'private': [
        ],
      }
    }
}

4.6. Programming Workload Manager APIs using Python

You can call workloadmgr apis in your python code. Here is the code snippet that initializes the workloadmgr client and invokes workloadmgr apis to calculate resources consumed by each tenant in the cloud.

  1. First import keystone modules and create authenticated sesssion with keystone. This code snippet assumes keystone v2, but can be easily extended to keystone v3 and multi domain environments. keystone session is used to get the list of users and tenants.
import math

from keystoneauth1.identity import v2
from keystoneauth1 import session
from keystoneclient.v2_0 import client

auth = v2.Password(username='admin', password='project1',
                   tenant_name='admin',
                   auth_url='http://192.168.1.104:5000/v2.0')
sess = session.Session(auth=auth)
keystone = client.Client(session=sess)
  1. Create workload manager client, passing the same credentials that were passed to create keystone client
from workloadmgrclient.v1.client import Client as wlmclient
from workloadmgrclient import utils

wclient = wlmclient('admin',                            # user name
                    'project1',                         # password
                    'admin',                            # tenant/project name
                    'http://192.168.1.104:5000/v2.0',   # authurl
                    region_name='RegionOne',            # region name
                    endpoint_type='publicURL',          # url type
                    service_type='workloads')           # service type

wclient.authenticate()
  1. Get the list of workloads by invoking wclient.workloads.list() api. There is a strict one-to-one mapping between workload manager cli and api, so it is easy to find an equivalent API that corresponds to CLI by exploring workloadmgrclient code.
# if you want to get workloads on a specific nfs share
#search_opts = {'all_workloads': True, 'nfs_share': '192.168.1.114:/home/centos/nfsshare'}

search_opts = {'all_workloads': True}
workloads = wclient.workloads.list(search_opts=search_opts)
tenant_usage = {}

totalvms = 0
for w in workloads:
    search_opts = { }
    search_opts['workload_id'] = w.id
    search_opts['all'] = True
    snapshots = wclient.snapshots.list(detailed=True, search_opts=search_opts)
    wl = utils.find_resource(wclient.workloads, w.id)
    totalvms += len(wl.instances)
    total_size = 0
    for s in snapshots:
        total_size += s.size

    tenant_usage[w.project_id] = tenant_usage.get(w.project_id, {})
    tenant_usage[w.project_id]['workloads'] = tenant_usage.get(w.project_id, {}).get('workloads', {})
    tenant_usage[w.project_id]['workloads'][w.id] = {'workload': w, 'size': total_size}
    tenant_usage[w.project_id]['total_vms'] = totalvms
  1. Print the usage by tenant basis
def convert_size(size_bytes):
    if size_bytes == 0:
        return "0B"
    size_name = ("B", "KB", "MB", "GB", "TB", "PB", "EB", "ZB", "YB")
    i = int(math.floor(math.log(size_bytes, 1024)))
    p = math.pow(1024, i)
    s = round(size_bytes / p, 2)
    return "%s %s" % (s, size_name[i])

for project_id, usage in tenant_usage.iteritems():
    print "Storage Usage for tenant '%s' [%s]:\n" % (keystone.tenants.get(project_id).name, project_id)
    total_size = 0
    for w_id, wl in usage['workloads'].iteritems():
        w = wl['workload']
        print '\t%s\t%s\t%s\t%s\t%s' % (w.id, w.name, w.description,
                                        w.status, convert_size(wl['size']))
        total_size += wl['size']

    print '\n\tTotal Storage: %s\n' % convert_size(total_size)
    print '\tTotal VMs protected: %d\n' % usage['total_vms']
    print

5. TrilioVault Configurator API

5.1. Introduction

Deployment Guide describes TrilioVault configuration as a GUI driven process. TrilioVault Configurator GUI relies on set of HTTP calls to successfully configure the appliance. Though these are not RESTful APIs, we intend to document these APIs in the hope that TrilioVault configuration process can be easily integrated with end user cloud life cycle management engines. In the future we may replace these APIs with RESTful APIs to make integration with configuration management tools easy.

5.2. API Listing

5.2.1. login

Login to the TrilioVault Configurator.

POST – https://{IP}/login

Request Parameters

Name Style Type Description
IP URI String IP of TrilioVault Machine preferably Virtual IP.

Request Body

Name Style Type Description
username Body String Username of configurator
password Body String Password of configurator

Sample Request:

curl -k **--cookie-jar /tmp/login_cookie** --dump-header - https://192.168.3.67/login -F username=admin -F password=password

Sample Response

HTTP/1.0 303 See Other
Date: Thu, 19 Jul 2018 06:29:44 GMT
Server: WSGIServer/0.1 Python/2.7.12
Content-Length: 0
Location: https://192.168.3.67/login
Content-Type: text/html; charset=UTF-8
Set-cookie: beaker.session.id=9777d8d4dbd4e3ee93819b3ef1bb29c990bc70baYTinb+8FgZGIjeGBs+15jQ==E4hQDNpE55yv3C3C0i4GFjX+dCKd13TjGdx2N4/jQawdpIDnz9xjkO3mJClK0UTdQvotgfoVzMcF9g2jHhFZSX73EwaPxtITE/oYRqjUjL/7rg4tXMua1KlBn+AhjwCD5H3kxADclet9; httponly; Path=/

Response Status

303

As it redirects the web page.

  • In case of valid authorization, the API returns the cookie value which has to be stored in a file to use with other APIs
  • In case of invalid authorization, there won’t be any cookie in the response header
   

Prerequisites for the API

None

5.2.2. configure_openstack

Send details to configure your TrilioVault Cluster.

POST – https://{IP}/configure_openstack

Request Parameters

Name Style Type Description
IP URI String IP of TrilioVault Machine preferably Virtual IP

Request Body

Name Style Type Description
triliovault-hostnames Body String Host Ips with names(e.g 192.168.18.11=tvm11)
virtual-ip Body String Virtual IP address
admin-username Body String tvault username
admin-password Body String tvault password
admin-tenant-name Body String Project names
keystone-admin-url Body String keystone admin endpoint
keystone-public-url Body String keystone public endpoint
name-server Body String Name server address (e.g 8.8.8.8)
domain-search-order Body String Domain search order
region-name Body String Region name
backup_target_type Body String Backup target type( e.g NFS)
create-file-system Body String True/False
storage-local-device Body String device location (e.g /dev/sdb)
storage-nfs-export Body String NFS mount point (e.g. 192.168.1.33:/mnt/tvault)
swift-auth-version Body String SWIFT auth version
swift-auth-url Body String SWIFT auth URL
swift-username Body String SWIFT username
swift-password Body String SWIFT password
domain-name Body String Domain name
ntp-enabled Body String True/False
ntp-servers Body String NTP server
timezone Body String TimeZone (e.g. Etc/UTC)
trustee-role Body String Openstack trustee role (e.g admin)
enable_tls Body String on/off
cert Body String Cert file
privatekey Body String Private key file
s3-access-key Body String S3-Access-Key file
s3-secret-key Body String S3-Secret-Key file
s3-region Body String S3 region (e.g. us-east-2)
s3-bucket Body String S3 bucket
s3-endpoint-url Body String S3 endpoint URL
s3-use-ssl Body String True/False
s3-backend-type Body String S3 backend (e.g Amazon)
workloads-import Body String Import workloads from backend (on/off)

Sample Request

curl --dump-header - -k --cookie '/tmp/login\_cookie' --data 'triliovault-hostnames=192.168.18.11=tvm11&virtual-ip=192.168.18.21&admin-username=admin&admin-password=password&admin-tenant-name=admin&keystone-admin-url=http://192.168.9.10:35357/v3&keystone-public-url=http://192.168.9.10:5000/v3&name-server=8.8.8.8&domain-search-order=triliodata.demo&region-name=RegionOne&backup\_target\_type=NFS&create-file-system=False&storage-local-device=/dev/sdb&storage-nfs-export=192.168.1.33:/mnt/tvault&swift-auth-version=&swift-auth-url=&domain-name=default&ntp-enabled=True&ntp-servers=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org&timezone=Etc/UTC&trustee-role=\_member\_&swift-username=&swift-password=&enable\_tls=off&cert=&privatekey=&s3-access-key=&s3-secret-key=&s3-region=us-east-2&s3-bucket=automation&s3-endpoint-url=http://192.168.1.119:9000&s3-use-ssl=False&s3-backend-type=Amazon&workloads-import=on' 'https://192.168.18.21/configure\_openstack'

Sample Response

HTTP/1.0 303 See Other
Date: Thu, 19 Jul 2018 12:31:49 GMT
Server: WSGIServer/0.1 Python/2.7.12
Content-Length: 0
Location: https://192.168.18.21/task_status_openstack
Content-Type: text/html; charset=UTF-8
Set-cookie: beaker.session.id=0871116216a00ed6067895d1f9f3c0b2a9f073caBIlRuzITtgQGnrdG5h4t7w==KToVlMPJfaT8n8vvPt15eRIS7V8jE8/rXLp8UEiB7i8AHyhs2s39buh1ioIxmLze4sOqFkRz/b6FSopn2KjHVEXIcYYaZ+dO0PeGuCn1g0jqr4Bw6DjYi6WXVFwy3yyimdooOCQpZy9xfCH0EPQNosvEbr7KawPoamYCA3/cTKycQcRzcDcTcvHwqGaFbaNmBevRy5x98Mt+HEXSbDCeg3dWQnPRI34=; httponly; Path=/

Response Status

303

As it redirects the web page.

  • In case of successful execution, the Location header shows path of task_status_openstack
  • In case of invalid parameter, the Location header shows path of configure_openstack
  • In case of invalid authorization, the Location header shows path of login
   

Prerequisites for the API

You should pass the cookies stored by login API in the request header.

5.2.3. populate_variables

Runs ansible playbook for populating variables.

GET – https://{IP}/populate_variables

Request Parameters

Name Style Type Description
IP URI String IP of TrilioVault Machine preferably Virtual IP.

Sample Request:

curl -k --dump-header - --cookie /tmp/login_cookie https://192.168.3.67/populate_variables

Sample Response:

HTTP/1.0 200 OK
Date: Thu, 19 Jul 2018 08:36:59 GMT
Server: WSGIServer/0.1 Python/2.7.12
Content-Length: 3830
Content-Type: text/html; charset=UTF-8
Set-cookie: beaker.session.id=f9305dd2a35d7d51b3ff9f17d0e1e6f510c849b3Rr5rsfjmMYHr8hg+XO/pSA==5giWhm4ACPvtMTWNxq+rDz1B+fBOw4R1MObnGbRjlTHGCA86AI6EC19lBAzdW53QZI0MLHiyuwQPxJin0EfYuZwMHeyEgEoZDCAWEdVW0WhuwHt6aIh18X8NoXq4TN1LQZ4uMKJGiRc+v0IZQ7BbjNDPmZcG2ChT3Mfo5zkoO4R5hh+jlaKOItqyrg==; httponly; Path=/
<!DOCTYPE html>
<html lang="en">
<head>
. . . < HTML CONTENT(Ansible output) > . . .

Response Status:

200 On successful call
303 Unauthorized Access
500 Occurrence of Error/Exception
405 Invalid call parameter

Prerequisites for the API:

You should pass the cookies stored by login API in the request header.

5.2.4. configure_host

Runs ansible playbook for configuring host.

GET – https://{IP}/configure_host

Request Parameters

Name Style Type Description
IP URI String IP of TrilioVault Machine preferably Virtual IP.

Sample Request:

curl -k --dump-header - --cookie /tmp/login_cookie https://192.168.3.67/configure_host

Sample Response:

HTTP/1.0 200 OK
Date: Thu, 19 Jul 2018 06:29:21 GMT
Server: WSGIServer/0.1 Python/2.7.12
Content-Length: 48205
Content-Type: text/html; charset=UTF-8
Set-cookie: beaker.session.id=ee8540996f9a86950fe3b10aee6e7d9d3d0bea9cDtKrMjuIzRgYjkCXbbZEVA==nzM9ZVbZ76MmrWmCj5puNFFFVZ7RukGbOeptNLQsk/PCWdzOvM3e52n29U4s/TqfRoh1fZu/JZxKUey8IjzoatdnPAV37hzjCnMHWW5uCxb3xJr0FCVqEWNZF9QdBaOquoOGb3JQl8hv5O+iRvSXlwJnkf4OyBONhsSXadEiKgmP0bsf/MR9W9RyTA==; httponly; Path=/
<!DOCTYPE html>
<html lang="en">
<head>
. . . <HTML content(Ansible output)> . . .

Response Status

200 On successful call
303 Unauthorized Access
500 Occurrence of Error/Exception
405 Invalid call parameter

Prerequisites for the API

You should pass the cookies stored by login API in the request header.

5.2.5. configure_workloadmgr

Runs ansible playbook for configuring workloadmanager.

GET – https://{IP}/configure_workloadmgr

Request Parameters

Name Style Type Description
IP URI String IP of TrilioVault Machine preferably Virtual IP.

Sample Request:

curl -k --dump-header - --cookie /tmp/login_cookie https://192.168.3.67/configure_workloadmgr

Sample Response:

HTTP/1.0 200 OK
Date: Thu, 19 Jul 2018 06:29:21 GMT
Server: WSGIServer/0.1 Python/2.7.12
Content-Length: 48205
Content-Type: text/html; charset=UTF-8
Set-cookie: beaker.session.id=ee8540996f9a86950fe3b10aee6e7d9d3d0bea9cDtKrMjuIzRgYjkCXbbZEVA==nzM9ZVbZ76MmrWmCj5puNFFFVZ7RukGbOeptNLQsk/PCWdzOvM3e52n29U4s/TqfRoh1fZu/JZxKUey8IjzoatdnPAV37hzjCnMHWW5uCxb3xJr0FCVqEWNZF9QdBaOquoOGb3JQl8hv5O+iRvSXlwJnkf4OyBONhsSXadEiKgmP0bsf/MR9W9RyTA==; httponly; Path=/
 <!DOCTYPE html>
 <html lang="en">
 <head>
 . . . <HTML content(Ansible output)> . . .

Response Status:

200 On successful call
303 Unauthorized Access
500 Occurrence of Error/Exception
405 Invalid call parameter

Prerequisites for the API

You should pass the cookies stored by login API in the request header.

5.2.6. register_workloadtypes

Registers workloadtypes. TrilioVault supports two types of workloads, Serial and Parallel.

GET – https://{IP}/register_workloadtypes

Request Parameters

Name Style Type Description
IP URI String IP of TrilioVault Machine preferably Virtual IP.

Sample Request:

curl -k --dump-header - --cookie /tmp/login_cookie https://192.168.3.67/register_workloadtypes

Sample Response:

HTTP/1.0 200 OK
Date: Thu, 19 Jul 2018 10:56:24 GMT
Server: WSGIServer/0.1 Python/2.7.12
Content-Length: 21
Content-Type: application/json
Set-cookie: beaker.session.id=e8cc3874e13108f7c391c16bb1b86049a9382b5bWN8zJjICOyo8xqp85NWibQ==7roz5uM5F3lfnHPrvxRfg74omg0o2KUO2iB6WNG/Os9STzuRac3vdf+/Ou8axO+o9SIiL0k4f8WU/HOj7d8PoTvLSplJnFb/z/XSSiOAalv8qUPD8CkpsJokjrpI7aC6Dwj1NjCPxZJxNAw4w50o4NUBz0gRYlrP8qR9zfkKP5/Vh4GfCc0wK9WoNA==; httponly; Path=/
{"status": "Success"}

Response Status

200 On successful call
303 Unauthorized Access
500 Occurrence of Error/Exception
405 Invalid call parameter

Prerequisites for the API

You should pass the cookies stored by login API in the request header.

5.2.7. workloads_import

Import workloads from backup storage, if set to true while configuring.

GET – https://{IP}/workloads_import

Request Parameters

Name Style Type Description
IP URI String IP of TrilioVault Machine preferably Virtual IP.

Sample Request:

curl -k --dump-header - --cookie /tmp/login_cookie https://192.168.3.67/workloads_import

Sample Response:

HTTP/1.0 200 OK
Date: Thu, 19 Jul 2018 11:12:46 GMT
Server: WSGIServer/0.1 Python/2.7.12
Content-Length: 21
Content-Type: application/json
Set-cookie: beaker.session.id=938d3e26dccd23cae723b0907eb629506497c75adUkV1PVjpP6n30h2uuEgRQ==gRnFVDeCvc7pJIyOvcrWWQpFEYfzB9qDC6OL2WmCc+dfjfjrqVp0OrovWUkUQG7bn2rxe7FqRZPZKdodYnCyySUR9G/sEcsdrOSwpx3UVZ+7haGAZRcNMNVgv1ZWRLA3ZI7qYiCxKBk6825WsEbv92ZM3wYtXjI9z9JvCrKPaWJcI+PlEY/9eNTUIg==; httponly; Path=/
{"status": "Success"}

Response Status

200 On successful call
303 Unauthorized Access
500 Occurrence of Error/Exception
405 Invalid call parameter

Prerequisites for the API

  • You should pass the cookies stored by login API in the request header.
  • Import workloads option must be true while calling /configure_openstack API.

5.3. Steps to Configure the Appliance

Follow the steps mentioned below in the provided order to successfully configure the appliance.

The steps should be executed only if the previous step gets executed successfully.

  1. Login
    1. API to be called : /login
    2. It generates a cookie when valid credentials are provided and this cookie is going to be used by each of the following steps.
    3. Refer sample request provided in the /login API section.
    4. This API can be called again if the cookie expires while performing any of the following steps and the regenerated cookie can be used to continue the process.
  2. Set openstack configuration parameters
    1. API to be called : /configure_openstack
    2. The request body should contain all the required parameters to configure the host with Openstack including the backup type.
    3. Refer sample request provided in the /configure_openstack API section.
    4. All the steps mentioned below use these parameters for their respective purposes.
    5. This step is mandatory for the first time configuration.
    6. If this step is not followed during re-configuration, then the next steps use the previously generated configuration parameters.
  3. Populate configurator variables
    1. API to be called : /populate_variables
    2. It uses the configuration parameters, set by /configure_openstack API to populate variables to be used during configuration process.
    3. This is a mandatory step.
    4. Refer sample request provided in the /populate_variables API section.
  4. Configure the Host
    1. API to be called : /configure_host
    2. It uses the configuration parameters, set by /configure_openstack API to configure the host(s)
    3. This is a mandatory step.
    4. Refer sample request provided in the /configure_host API section.
  5. Configure Workloadmanager
    1. API to be called : /configure_workloadmgr
    2. It uses the configuration parameters, set by /configure_openstack API to configure Workloadmanager and some additional services.
    3. This is a mandatory step.
    4. Refer sample request provided in the /configure_workloadmgr API section.
  6. Register Workloadtypes
    1. API to be called : /register_workloadtypes
    2. It uses the configuration parameters, set by /configure_openstack API to register workload types.
    3. This is a mandatory step.
    4. Refer sample request provided in the /register_workloadtypes API section.
  7. Import Workloads from Backup target
    1. API to be called : /workloads_import
    2. It uses the “import_workloads” parameter, set by /configure_openstack API to import previous workloads from backup target.
    3. This is an optional step only to be used if “import_workloads” parameter is set to “On” by /configure_openstack API.
    4. Refer sample request provided in the /workloads_import API section.