Trilio 4.1 Release Notes
Trilio release 4.1 introduces new features and capabilities including:
Openstack Ussuri support
New File Recovery Process
Increased Openstack independency
Installation Optimization for Kolla Ansible Openstack, Ansible Openstack, and Red Hat Openstack Platform
Support for External MySQL/MariaDB databases
Incremental Backup for nova booted instances
Support of Openstack User Groups
New Quota: Snapshots
S3 Support for Kolla Ansible Openstack
UI enhancement for selective Restore
Trilio 4.1.94 is the GA release of Trilio 4.1
Release Versions
Packages
s3fuse
python package
4.1.94
tvault-configurator
python package
4.1.94
workloadmgr
python package
4.1.94
workloadmgrclient
python package
4.1.94
contegoclient
python package
4.1.94
dmapi
deb package
4.1.94
python3-dmapi
deb package
4.1.94
tvault-contego
deb package
4.1.94
python3-tvault-contego
deb package
4.1.94
tvault-horizon-plugin
deb package
4.1.94
python3-tvault-horizon-plugin
deb package
4.1.94
s3-fuse-plugin
deb package
4.1.94
python3-s3-fuse-plugin
deb package
4.1.94
workloadmgr
deb package
4.1.94
dmapi
rpm package
4.1.94
python3-dmapi
rpm package
4.1.94
tvault-contego
rpm package
4.1.94
python3-tvault-contego
rpm package
4.1.94
tvault-horizon-plugin
rpm package
4.1.94
python3-tvault-horizon plugin-el8
rpm package
4.1.94
python-s3fuse-plugin-cent7
rpm package
4.1.94
python3-s3fuse-plugin
rpm package
4.1.94
Containers and Gitbranch
Gitbranch
stable/4.2
RHOSP13 containers
4.1.94-rhosp13
RHOSP16.0 containers
4.1.94-rhosp16
RHOSP16.1 containers
4.1.94-rhosp16.1
Kolla Ansible Ussuri containers
4.1.94-ussuri
Openstack Ussuri support
Trilio 4.1 continues to enable Openstack versions and Distributions, allowing Trilio customers to stay up to date with Openstack releases.
Trilio 4.1 introduces full support for Openstack Ussuri for Kolla Ansible Openstack, Ansible Openstack, and Canonical Openstack. In addition, Trilio 4.1 does of course support the active long-term releases from Red Hat and Canonical. Openstack users of those releases can continue to use the latest Trilio functionalities.
New File Recovery Manager Process
Since Trilio was released for the first time was the File Recovery Manager instance in tandem with Trilio. The File Recovery Manager instance helped customers to easily and quickly fetch and restore files and folders directly from the backups.
Over the years did more and more customers request to have the File Recovery Manager on their own images or on a specific Linux distribution. We looked into the possibility to create multiple versions of the File Recovery Manager which was identified as not getting to the point of flexibility our customers need.
The result was a revamp of the File Recovery Manager which allows the installation on any CentOS-based or Ubuntu-based instance.
Increased Openstack independency
Trilio has the goal to become an integrated part of Openstack since its first draft on a whiteboard. Back then were the Trilio services defined as sub-services of Nova and Trilio tied deeply into the already existing nova services and became an integral part of it.
Over the years did the nova service change and possibilities that were once available have been taken out from nova. This plus the required lengthy qualification of all Openstack Versions and Distributions made it clear that a change is required.
Trilio 4.1 is now a complete stand-alone service, which is communicating with nova and other Openstack services through APIs only. The goal of this independence is to speed up future qualification and requalification cycles to provide a broader support matrix again.
Installation optimization for Kolla Ansible Openstack, Ansible Openstack, and Red Hat Openstack Platform
Trilio's integration into Openstack already starts with the installation process. This process required manual installation steps in the past, which were hard to automize and scale on bigger environments.
Trilio 4.1 is therefore introducing Ansible Playbooks for Kolla-Ansible and Ansible Openstack, while the integration with Red Hat Director has been deepened. Further, the Trilio configurator does now allow to set the backup target on the Trilio Appliance directly based on Distribution.
Support for external MySQL/MariaDB
The Trilio Appliance provides its own database. A database that suits the needs of 99% of Trilio's customers. Some customers do have higher requirements. Be it performance, security, or just the general design of the Openstack itself.
For these customers and everyone who wants to use it is Trilio 4.1 introducing the possibility to configure Trilio with an external database.
Incremental Backups for nova booted instance root volumes
Openstack provides the possibility to start an instance from a Cinder Volume or directly using the Glance Image and a nova volume.
Trilio always provided incremental forever backups for all cinder volumes. Root-Volumes from nova-booted instances were always taken as a full backup of the Glance image and the actual VM root volume.
Trilio 4.1 does introduce incremental backups for nova booted instance root volumes. This allows Trilio 4.1 to provide incremental backups to any type of root volume.
Support for Openstack User Groups
Trilio is using the Openstack Keystone service to authenticate any user and to verify that the right permissions are set. Openstack Keystone allows to group users and set the permissions to the group.
These Openstack User Groups are now fully supported.
New Quota: Snapshots
Trilio 4.0 introduced the Quota functionality, which allowed to set quotas for the number of workloads, number of VMs and amount of storage used by a single tenant.
Trilio 4.1 extends this feature by the number of Trilio Snapshots that a Tenant is allowed to have.
S3 Support for Kolla Ansible Openstack
S3 is becoming the standard to transfer data to and from storage solutions. Trilio introduced S3 already in Version 3.0 but had to take it out for Kolla Ansible since Kolla Ansible has been added to the Support Matrix.
Trilio 4.1 is now closing that gap to other Openstack Distributions and provides full S3 support for Kolla Ansible Openstack Ussuri.
UI enhancement for the Selective Restore
The Selective Restore is the most powerful and complex restore Trilio has to offer. The UI needs to be easy to understand and help the user to fulfill its task.
Several points have been identified to improve this requirement of usability. The selective restore now allows to select or deselect all VMs at once. Further are the VMs now provided in an easy to overview list and the sub-controls can be expanded and collapsed as necessary.
Known Issues
This release contains the following known issues which are tracked for a future update.
Snapshots getting stuck in uploading stage on RHOSP13 with ISCSI based Volumes
Observation:
Login into the iscsi device is getting rejected for the Trilio service
Result is the Snapshot not moving forward until timing out
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
[Volume Backup Exclude] Excluded Ceph Volume after restore not mountable or formattable
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 formattable
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
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
[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
After reinitialize and import Openstack certificates are missing
Observation:
Reinitialize does not keep the already uploaded Openstack Certificates used to communicate with Openstack.
Workaround:
Upload Certificates again
CLI import changes scheduler trust value to disabled
Observation:
When the import functionality is used via CLI is the scheduler trust changed from enabled to disabled.
Workaround:
Configure/re-configure T4O with import option from UI after reinitialize.
Unable to get node details after reinitializing the Trilio Appliance
Observation:
After reinitializing was neither the UI nor CLI showing Node information
Workaround:
Restart wlm-workloads and wlm-cron services on Trilio nodes
systemctl restart wlm-workloadssystemctl restart wlm-cron
Snapshots fails with "object is not subscriptable" for many workload jobs at the exact same time
Oberservation:
Running more than 25 workloads at the exact same time leads to error
dmapi service is not responding
Snapshots fail with "object is not subscriptable"
Workaround:
Contact Trilio Support to implement a known workaround.
[Kolla Ansible] dmapi container stuck in restarting if storage backend changes
Observation:
Just changing the backup target in the Kolla Ansible configuration files and redeploying leads to dmapi container stuck in restart
Workaround:
Follow guide to Switch Backup Target on Kolla-Ansible
No operation is permitted in insecure way for ssl enabled Keystone URL
Observation:
SSL enabled Openstack
Backup and Restore jobs fail with with missing TLS CA certificate bundle error
Workaround:
Configure the Trilio appliance with Openstack CA provided
OR Provide Openstack CA to
/etc/workloadmgr/ca-chain.pem
Last updated