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