Open Stack

Hi Bekir,

I'm very happy to answer your questions. See me comments in line.

On Sat, Jan 23, 2021 at 8:24 AM Bekir Fajkovic <
bekir.fajkovic at citynetwork.eu> wrote:

>
> The questions:
> ------------------------
>
> Having the fact that Trove Victoria release provides Docker containers as
> a new way of database instance provisioning, i am wondering how far the
> project
> is developed in terms of covering the different types of databases. What i
> can see by mainly parsing the code provided on Github, those seem to be
> officially released:
>
> - MySQL
> - MariaDB
> - PostgreSQL
>
> and the rest of the planned database types are in "experimental" phase.
> And also, regarding certain types of databases (for example MySQL, version
> 5.7 and 8.0) only certain
> versions of the datastores seems to be supported, but not all.
>

MySQL 5.7.x is supported but 8.0 is in experimental.


> On the other hand, nothing regarding datastore versions supported for
> MariaDB and PostgreSQL seems to be
> mentioned somewhere. Could someone please confirm that as well as give
> some more details about it?
>

MariaDB 10.4.x and PostgreSQL 12.4 are supported. The other versions need
to be fully tested.


> I successfully managed to create certain versions of datastores in my
> devstack environment, belonging to those 3 database types mentioned above
> (and based on
> trovestack-generated dev guest image that is by default delivered with
> devstack installation), but not without some undesirable events. For
> example, i am able to register
> PostgreSQL datastore version 12 and instantiate a database instance of
> that version but not version 13 and above, where i get some
> hostname-related errors etc.
>

Yes, because PostgreSQL 13 has never been tested.


> Also, a question regarding the building of the production-ready guest
> image. As mentioned, Trovestack script is provided as a possible way of
> producing the images (by omitting
> dev option the Trove Guest Agent binaries are deployed into the
> instantiated VM). How does an image produced this way looks like? From
> where the base image is fetched,
> is it a "cloud based image" with cloud-init in it, are the automatic
> security and software patching features disabled in produced image, so that
> we do not get unexpected service
> interruptions when the OS suddenly decides to start updating itself etc..
>

If you look at trovestack script implementation, you can see it's
calling disk-image-create script from diskimage-builder, and there are some
elements[2] defined in trove repo[3] for building the image.

[1]: https://docs.openstack.org/diskimage-builder/latest
[2]: https://docs.openstack.org/diskimage-builder/latest/elements.html
[3]:
https://github.com/openstack/trove/tree/master/integration/scripts/files/elements


> Regarding the Trove Guest Agent service - i read in some Trove books
> previously that there are dedicated agents for each and every database
> type, is it the same situation
> in Victoria release, or is there an "universal" Guest Agent covering all
> the database types nowadays? Where is the code that adapts the Agent
> commands towards the database
> instances placed inside the project?
>

Trove never has dedicated agents for each and every database type, it's
using the same trove-guestagent but with different configurations for
different datastores.


> The backups - as i can see there seem to be some kind of dedicated
> docker-backup images involved in each database type. Could someone explain
> the internals of backup mechanisms
> inside Trove Victoria release in more details?
>

The backup container image is created to help trove-guestagent to achieve
datastore-agnostic (so we only need to maintain a universal guest image),
we shift the backup and restore functionalities and needed tools to a
dedicated container. The implementation can be found here[4].

[4]: https://github.com/openstack/trove/tree/master/backup


---
Lingxian Kong
Senior Software Engineer
Catalyst Cloud
www.catalystcloud.nz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210125/9697889d/attachment.html>