Each Trilio Workload has a dedicated owner. The ownership of a Workload is defined by:
OpenStack User - The OpenStack User-ID is assigned to a Workload
OpenStack Project - The OpenStack Project-ID is assigned to a Workload
OpenStack Cloud - The Trilio Serviceuser-ID is assigned to a Workload
OpenStack Users can update the User ownership of a Workload by modifying the Workload.
This ownership ensures that only the owners of a Workload are able to work with it.
OpenStack Administrators can reassign Workloads or reimport Workloads from older Trilio installations.
The import performance has been improved in the Trilio for OpenStack 4.3 release
As part of this design improvement, the importing of data will happen in parallel by optimal utilization of available resources on the appliance. Additionally, import of network and security group related tables will not happen during import operation; this will happen later on during the following operations:
Snapshot show in UI : When user clicks on snapshot hyperlink on horizon UI.
Snapshot show in CLI : When user triggers snapshot-show command in CLI.
Any restore : When user triggers any of the restores either from UI or CLI.
Note: The above import of network & security group related data will happen one only during the first run of any of the above operations.
Workload import allows a user to import Workloads directly from the Backup Target into the Trilio database.
The Workload import is designed to import Workloads, which are owned by the OpenStack Cloud.
It will not import or list any Workloads that are owned by a different cloud.
To get a list of importable Workloads use the following CLI command:
To import Workloads into the Trilio database use the following CLI command:
For every workload-importworkloads command triggered, the system will generate a jobid which will be displayed after successful workload-importworkloads command execution.
Respective import process can further be tracked using this jobid in a CLI provided starting T4O-4.3 release. User can add all workloads (which are to be imported) with a single workload-importworkloads command OR can trigger multiple such commands. For every command trigger, system will generate one unique jobid.
CLI details below:
The definition of an orphaned Workload is from the perspective of a specific Trilio installation. Any workload that is located on the Backup Target Storage, but not known to the TrilioVualt installation is considered orphaned.
Further is to divide between Workloads that were previously owned by Projects/Users in the same cloud or are migrated from a different cloud.
The following CLI command provides the list of orphaned workloads:
Running this command against a Backup Target with many Workloads can take a bit of time. Trilio is reading the complete Storage and verifies every found Workload against the Workloads known in the database.
OpenStack administrators are able to reassign a Workload to a new owner. This involves the possibility to migrate a Workload from one cloud to another or between projects.
Reassigning a workload only changes the database of the target Trilio installation. When the Workload was managed before by a different Trilio installation, will that installation not be updated.
Use the following CLI command to reassign a Workload:
A sample mapping file with explanations is shown below:
--project_id <project_id> List workloads belongs to given project only.
--workloadids <workloadid> Specify workload ids to import only specified workloads. Repeat option for multiple workloads.
--jobid <jobId> The ID returned by workload-importworkloads CLI command.
--migrate_cloud {True,False} Set to True if you want to list workloads from other clouds as well. Default is False.
--generate_yaml {True,False} Set to True if want to generate output file in yaml format, which would be further used as input for workload reassign API.
--old_tenant_ids <old_tenant_id> Specify old tenant ids from which workloads need to reassign to new tenant. Specify multiple times to choose Workloads from multiple tenants.
--new_tenant_id <new_tenant_id> Specify new tenant id to which workloads need to reassign from old tenant. Only one target tenant can be specified.
--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. Specifiy multiple times for multiple workloads.
--user_id <user_id> Specify user id to which workloads need to reassign from old tenant. only one target user can be specified.
--migrate_cloud {True,False} Set to True if want to reassign workloads from other clouds as well. Default if False
--map_file Provide file path(relative or absolute) including file name of reassign map file. Provide list of old workloads mapped to new tenants. Format for this file is YAML.