[Trove] Project udpate
As the official Victoria release is approaching and it has been a long time
silence for Trove in the upstream, I think it's good time for me as the
PTL for the last 3 dev cycles to have a project update. The things that
described below have not been achieved in one single dev cycle, but are some
significant changes since the 'dark time' of Trove project in the past. Tips
hat to those who have made contributions to Trove project ever before.
## Service tenant configuration
Service tenant configuration was added in Stein release, before that, it's
impossible to deploy Trove in the public cloud (even not for some private
due to security concerns) because the user may have access to the guest
instance which contains sensitive data in the config files, the users can
perform operations towards either storage or networking resources which may
bring much management overhead and make it easy to break the database
With service tenant configuration (which is currently the default setting in
devstack), almost all the cloud resources(except the Swift objects for
data) created for a Trove instance are only visible to the Trove service
As Trove users, they can only see a Trove instance, but know nothing about
Nova VM, Cinder volume, Neutron management network, and security groups
the hood. The only way to operate Trove instances is to interact with Trove
## Message queue security concerns
To do database operations, trove controller services communicate with
trove-guestagent service inside the instance via message queue service (i.e.
RabbitMQ in most environments). In the meantime, trove-guestagent
sends status update information to trove-conductor through the same
In the current design, the RabbitMQ username and password need to be
in the trove-guestagent config file, which brought significant security
for the cloud deployers in the past. If the guest instance is compromised,
guest credentials are compromised, which means the messaging system is
As part of the solution, a security enhancement was introduced in the Ocata
release, using encryption keys to protect the messages between the control
plane and the guest instances. First, the rabbitmq credential should only
access to trove services. Second, even with the rabbitmq credential and the
message encryption key of the particular instance, the communication from
guest agent and trove controller services are restricted in the context of
particular instance, other instances are not affected as the malicious user
doesn't know their message encryption keys.
Additionally, since Ussuri, trove is running in service tenant model in
devstack by default which is also the recommended deployment configuration.
Most of the cloud resources(except the Swift objects for backup data)
for a trove instance should only be visible to the trove service user, which
also could decrease the attack surface.
## Datastore images
Before Victoria, Trove provided a bunch of diskimage-builder elements for
building different datastore images. As contributors were leaving, most of
elements just became unmaintained except for MySQL and MariaDB. To solve the
problem, database containerization was introduced in Victoria dev cycle, so
that the database service is running in a docker container inside the guest
instance, trove guest agent is pulling container image for a particular
datastore when initializing guest instance. Trove is not maintaining those
That means, since Victoria, the cloud provider only needs to maintain one
single datastore image which only contains common code that is datastore
independent. However, for backward compatibility, the cloud provider still
needs to create different datastores but using the same Glance image ID.
Additionally, using database container also makes it much easier for
operations and management.
To upgrade from the older version to Victoria onwards, the Trove user has to
create backups before upgrading, then create instances from the backup, so
downtime is expected.
## Supported datastores
Trove used to support several datastores such as MySQL, MariaDB, PostgreSQL,
MongoDB, CouchDB, etc. Most of them became unmaintained because of a lack of
maintainers in the community.
Currently, only MySQL and MariaDB drivers are fully supported and tested in
upstream. PostgreSQL driver was refactored in Victoria dev cycle and is in
experimental status again.
Adding extra datastores should be quite easy by implementing the interfaces
between trove task manager and guest agent. Again, no need to maintain
datastore images thanks to the container technology.
## Instance backup
At the same time as we were moving to use container for database services,
also moved the backup and restore functions out of trove guest agent code
because the backup function is usually using some 3rd party software which
don't want to pre-install inside the datastore image. As a result, we are
container as well for database backup and restore.
For more information about the backup container image, see
There are many other improvements not mentioned above added to Trove since
* Access configuration for the instance.
* The swift backend customization for backup.
* Online volume resize support.
* XFS disk format for database data volume.
* API documentation improvement.
By the way, Catalyst Cloud has already deployed Trove (in Alpha) in our
cloud in New Zealand, we are getting feedback from customers. I believe
are other deployers already have Trove in their production but running an
version because of previous upstream situation in the past. If you are one
them and interested in upgrading to the latest, please either reply to this
email or send personal email to me, I would be very happy to provide any
or guidance. For those who are still in evaluation phase, you are also
to reach out for any questions. I'm always in the position to help in
#openstack-trove IRC channel.
Senior Software Engineer
-------------- next part --------------
An HTML attachment was scrubbed...