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
Last updated