OpenStack Trove, which was originally called Red Dwarf, is a project that was initiated by HP, and many others contributed to it later on, including Rackspace. The project was in incubation till the Havana release of OpenStack.
It was formally introduced in the Icehouse release in April 2014, and its mission is to provide scalable and reliable cloud DBaaS provisioning functionality for relational and non-relational database engines.
As of the Liberty release, Trove is considered as a big-tent service.
Big-tent is a new approach that allows projects to enter the OpenStack code namespace. In order for a service to be a big-tent service, it only needs to follow some basic rules, which are listed here. This allows the projects to have access to the shared teams in OpenStack, such as the infrastructure teams, release management teams, and documentation teams. The project should:
Align with the OpenStack mission
Subject itself to the rulings of the OpenStack Technical Committee
Support Keystone authentication
Be completely open source and open community based
At the time of writing this book, the adoption and maturity levels are as shown here:
The previous diagram shows that the Age of the project is just 2 YRS and it has a 27% Adoption rate, meaning 27 of 100 people running OpenStack also run Trove.
The maturity index is 1 on a scale of 1 to 5. It is derived from the following five aspects:
The presence of an installation guide
Whether the Adoption percentage is greater or lesser than 75
Stable branches of the project
Whether it supports seven or more SDKs
Corporate diversity in the team working on the project
Without further ado, let's take a look at the architecture that Trove implements in order to provide DBaaS.
The trove project uses some shared components and some dedicated project-related components as mentioned in the following subsections.
The Trove system shares two components with the other OpenStack projects: the backend database (MySQL/MariaDB), and the message bus.
This component is responsible for providing the RESTful API with JSON and XML support. This component can be called the face of Trove to the external world since all the other components talk to Trove using this. It talks to the task manager for complex tasks, but it can also talk to the guest agent directly to perform simple tasks, such as retrieving users.
The task manager is the engine responsible for doing the majority of the work. It is responsible for provisioning instances, managing the life cycle, and performing different operations. The task manager normally sends common commands, which are of an abstract nature; it is the responsibility of the guest agent to read them and issue database-specific commands in order to execute them.
The guest agent runs inside the Nova instances that are used to run the database engines. The agent listens to the messaging bus for the topic and is responsible for actually translating and executing the commands that are sent to it by the task manager component for the particular datastore.
Let's also look at the different types of guest agents that are required depending on the database engine that needs to be supported. The different guest agents (for example, the MySQL and PostgreSQL guest agents) may even have different capabilities depending on what is supported on the particular database. This way, different datastores with different capabilities can be supported, and the system is kept extensible.
The conductor component is responsible for updating the Trove backend database with the information that the guest agent sends regarding the instances. It eliminates the need for direct database access by all the guest agents for updating information. This is like the way the guest agent also listens to the topic on the messaging bus and performs its functions based on it.
The following diagram can be used to illustrate the different components of Trove and also their interaction with the dependent services:
