Now that the Trove system is installed, the next step is to build the images that we will use for the DBaaS to function properly. This is possibly the most important step as this will be the gold standard that Trove will use for a particular data store.
For the sake of simplicity and especially for testing, we can use the prebuilt images that are available from OpenStack itself. These images should strictly be used for testing and development use and should not be used in a production environment. The images are available for download and are located at http://tarballs.openstack.org/trove/images/ubuntu/.
In order to use the images from the preceding repository, we can only use the 10.0.0.0/24
subnet in the FIXED_RANGE
of DevStack. This is because of the fact that the default gateway for these images is set to 10.0.0.1
.
In our case, we have used 10.1.10.0/24
, so the default gateway needs to be 10.1.10.1
. Hence, the images cannot be used directly. We have two options to use the prebuilt images:
~/devstack/unstack.sh
script and remove the DevStack install, change the FIXED_RANGE
variable, and rerun the ~/devstack/stack.sh
scriptGlance
repositoryWe would, however, recommend you create a new image using Disk Image Builder (DIB) by following the instructions in this chapter.
For use with production systems, it is recommended to create our own images; that way, we can conform to standards set by the company's security team. We will also deal with creating the DIB elements that you can use to install other components.
A guest image is technically just another Nova template on which some additional customization has been performed. The guest image technically has to fulfill the following aspects:
The image, like all the other OpenStack images, will be stored in Glance so that it can be called and used by Nova and finally by Trove to orchestrate and manage the database engine that will be installed in the system itself.
As we have already seen in the previous chapters, the guest agent is different for different database engines, and hence the correct version of the guest agent needs to be installed on the system.
The images that are available for testing from the previously mentioned URL don't come with an installed guest agent, but they do so during boot time. This was done intentionally so that any changes are reflected quickly without us having to build the guest image if we change the configuration of the guest agent.
We should also remember that one image can only house one guest agent at the moment, and hence if we have to create two Trove data stores, we need to create two images. Also, images need to be created per hypervisor type if multi-hypervisor deployment is being used in OpenStack. as shown in the following:
In order to understand the images and why they are created in the way that they are, let us take a look at the way the boot Trove images behave in the system. In order to check this, we will see exactly what happens when a trove create
command is executed.
The trove create
command is used to spin up a database instance. We will see the details of the command and the options later in this book, but for now, let's take a look at the sample command.
trove create <name> <flavor id> --size <Disk Volumes> --datastore <Database engine name> --datastore_version <version>