Trilio 4.0 Release Notes

Trilio release 4.0 introduces new features and capabilities including

• Openstack Train support

• Trilio Openstack Quota integration

• Openstack CLI integration

• CLI restore of networks only

• CLI restore of security groups only

• Disk integrity check after Snapshots

• Performance Enhancements for big environments

• Enablement of rolling upgrades

Trilio 4.0.92 is the GA release of Trilio 4.0 Trilio 4.0.115 is the first patch release of Trilio 4.0.

Openstack Train support

Trilio 4.0 continues to enable Openstack versions and Distributions, allowing Trilio customers to stay up to date with Openstack releases.

Trilio 4.0 introduces full support for Openstack Train over the four supported Distributions. In addition, does Trilio 4.0 of course support longterm releases, giving Openstack users of those releases the possibility to use the latest Trilio functionalities.

Trilio Openstack Quota integration

Trilio for Openstack integrates natively with Openstack and we are happy to announce, that Trilio made another important step.

With the possibility to create Project quotas for Workloads, VMs and Storage usage can Openstack administrators now clearly control how Trilio is used by any tenant.

Combining the Quota feature with the already available policies enables Openstack administrators to define exactly what an Openstack Project can do or can't do with Trilio.

Openstack CLI integration

Trilio has been using its very own Python based CLI client, the workloadmgr client.

This client has followed the Openstack standards for CLI clients and is now again following the established standards, which integrated all Python Openstack clients into a single Openstack Python CLI client.

Trilio 4.0 enables the usage of the Openstack client for the most common commands required during the daily work with Trilio.

CLI restore of networks and security groups only

Trilio restore possibilities allowed to restore any VM and its attached resources as required. Still it was always necessary to restore the complete VM to get the networks or security groups tied to that VM or backup.

Trilio 4.0 introduces the possibility to restore only the networks or security groups directly from the CLI.

Disk integrity check after a backup

Trilio always protected the integrity of any Snapshots. However, when Trilio identified a failure in the integrity did the backup job fail and not only was the Snapshot with a failed integrity lost but the following backups as well.

To overcome this limitation did Trilio enhance the already available disk integrity check and implemented it at the end of each Snapshot. When it is detected that a Snapshot disk integrity is not provided, will the next Snapshot automatically be a full Snapshot.

That way ensuring that future backups are again having a reliable disk integrity.

Performance enhancements for big environments

With the success of Trilio around the world was it only a question of time until Trilio would be tested against a real big environment with thousands of API calls per second.

We are happy to say that our solution did keep up to the task, but it still showed potential to improve even more. And that improvement comes with a small change on the Trilio Appliance, which allows the load-balancing of incoming API calls against a complete Trilio cluster, instead of a master node.

Enablement of rolling upgrades and updates

Trilio has been part of some Openstack environments for years, going through the process of updating and upgrading together with the environment and stand alone.

This upgrade process so far was always a complete uninstallation and reinstallation of the Trilio solution, which was very time consuming and frustrating for Openstack Administrators.

Trilio 4.0 changed the way the Trilio Appliance is build to allow to update and upgrade of the complete Trilio solution.

The exact process will be announced together with the first patch release of Trilio 4.0.

Known Issues

This release contains the following known issues which are tracked for a future update.

Workloadmgr Quota feature does not support RHOSP13 & Canonical Queens Horizon

The workloadmgr Quota feature is still fully supported through CLI.

[Openstack Ansible] snapshot mount failed with error 'Permission denied'

Observation:

• It has been observed that on non-kolla, non-rhosp setups, such as openstack ansible, nova user id is not same as we consider as default(162).

• Another observation is that, the id which is assigned to nova, was conflicting with id of system user in TVM, this created a situation where we had to redeploy Openstack.

Workaround:

• Update permissions of /var/triliovault-mounts to 755

Snapshots are getting stuck when wlm-workloads service stops during a backup process

Observation:

• When wlm-workloads service gets stopped on the node with an active snapshot process does the process get stuck without erroring.

Workaround:

• Restart wlm-workloads service on Trilio cluster, snapshot will throw error.

[Volume Backup Exclude] Excluded Ceph Volume after restore not mountable or formatable

Observation:

• VM Volumes stored on Ceph are successfully excluded from backup if desired

• Restore does create empty Ceph Volume

• created empty Ceph Volume is not attachable or formatable

Restored VMs have blank metadata config_drive attached

Observation:

• For every restore will the metadata config_drive be set as blank value

• No impact on restored VMs known

Workaround

• delete metadata config_drive

• or set desired value

Scheduler trust not getting imported together with workload

Observation:

• Workload gets imported successfully

• original User and Project still exist (ownership stays same)

• All schedulers trusts are defined as disabled

Workaround:

• Edit any (just 1) workload, modify the scheduler policy and submit

• trust will be recreated

TVM reconfig fails when adding new Trilio VM to the cluster

Observation:

• TVault re-configuration while adding nodes to existing TVM cluster fails at "Configuring Trilio Cluster"

• Reason is that the prev mysql password was not working and mysql root access has be reset.

Workaround:

• remove /root/.my.cnf file on already configured TVM and reconfigure it

Database does not sync after Trilio cluster gets new nodes

Observation:

• After TVault re-configuration post addition of 2 more nodes to existing TVM cluster ("import workloads" was not seleted), the databases do not sync against already existing TVM.

• It is expected that while adding the 2 new nodes, the db on node1 should get synced up with 2 new nodes and the existing workloads should be available post the reconfig on the new 3 node TVM cluster.

Workaround:

• Run workload import from CLI

Workload scheduler gets disabled after primary node goes down

Observation:

• Deactivating the primary node of a TVM cluster deactivates scheduler of associated workloads.

Workaround:

• restart wlm-cron service on new primary node

[exclude_boot_disk] Data on boot disk gets backed up despite exclusion

Observation:

• VM was set with metadata exclude_boot_disk_from_backup set to true

• Restored instance showed, that data was backed up and restored

Post workload reassignment, scheduler trust gets disabled even if Established before reassignment

Observation:

• Workload with scheduler trust established gets reassigned to new project

• scheduler trust is getting disabled

Workaround:

• Edit the workload to enable scheduler

Additional parameters required in rc file to run wlm commands from openstack cli

Observation:

• using workloadmgr commands with Openstack CLI still requires OS_TENANT_ID and OS_USER_DOMAIN_ID

Workaround:

• edit rc file and add required fields