Some questions regarding OpenStack Trove Victoria release

Lingxian Kong anlin.kong at gmail.com
Tue Feb 16 10:32:53 UTC 2021


Hello again, Bekir.

There is no one currently working (or ever worked) on SQL Server support in
Trove, but I don't think it is difficult to add. My only concern is, given
the SQL Server is an enterprise database platform, how is it going to be
tested in the upstream CI?

---
Lingxian Kong
Senior Cloud Engineer (Catalyst Cloud)
Trove PTL (OpenStack)
OpenStack Cloud Provider Co-Lead (Kubernetes)


On Tue, Feb 16, 2021 at 10:27 PM Bekir Fajkovic <
bekir.fajkovic at citynetwork.eu> wrote:

> Hello again!
>
> One additional question here:
>
> Regarding the status of MSSQL provisioning inside the Trove project, is
> this abandoned or is it going to be provided in the future?
> Do You have any developers involved in development of this particular
> datastore type right now and how easy it would be to add
> it to the Trove Victoria concept?
>
> I guess most of the work should be done on modifying the Guest Agent to
> adapt to MSSQL, probably this part of the project:
>
> https://github.com/openstack/trove/tree/master/trove/guestagent
>
> If there is no ongoing development work towards integration of MSSQL into
> Trove right now, maybe we at City Network could
> contribute with that particular work by allocating suitable developer
> resources?
>
> Best Regards
>
> *Bekir Fajkovic*
> Senior DBA
> Mobile: +46 70 019 48 47
>
> www.citynetwork.eu | www.citycloud.com
>
> INNOVATION THROUGH OPEN IT INFRASTRUCTURE
> ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED
>
> ----- Original Message -----
> ------------------------------
> From: Lingxian Kong (anlin.kong at gmail.com)
> Date: 01/26/21 10:51
> To: Bekir Fajkovic (bekir.fajkovic at citynetwork.eu)
> Cc: openstack-discuss (openstack-discuss at lists.openstack.org)
> Subject: Re: Re[2]: Some questions regarding OpenStack Trove Victoria
> release
>
> On Tue, Jan 26, 2021 at 8:43 PM Bekir Fajkovic <
> bekir.fajkovic at citynetwork.eu> wrote:
>
>> Hi!
>>
>> Thanks a lot for the kind answers and explanations, now the picture of
>> the concept and the current development situation overall is much clearer
>> to me.
>>
>> Regarding the question about different types of Guest Agents acquired,
>> depending on the database type, that i asked, it is mainly based on the
>> information i read
>> about in the latest edition of the book "*Openstack Trove Essentials*"
>> by Alok Shrivastwa and Sunil Sarat that i purchased recently.
>>
>> For example, as mentioned in the book:
>>
>>
>> *- 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.* (page 6)
>> *- The Guest Agent code is different for every datastore that needs to be
>> supported and the Guest Agent for that particular datastore is installed on
>> the corresponding image of the datastore version. *(page 10)
>> *- 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. *(page 58)
>>
>
> Some of those have been changed and not the case any more. After database
> containerization, there is no database related stuff installed in the guest
> image. However, it's correct that different datastores are implemented as
> different drivers, so you can say "The Guest Agent code is different".
>
>
>> When it comes to guest image creation, i found now the places in the code
>> that are used, as well as the acquired elements. A call to the function
>> *build_guest_image() *is performed, involving those needed elements
>> as minimal requirements:
>>
>> - *ubuntu-minimal *(which also invokes *ubuntu-common* i think)
>> - *cloud-init-datasources*
>> - *pip-and-virtualenv*
>> - *pip-cache*
>> - *guest-agent*
>> - ${guest_os}-*docker*
>> - *root-passwd*
>>
>> ref:
>>
>> https://github.com/openstack/trove/blob/master/integration/scripts/functions_qemu
>>
>> So, when it comes to my question regarding the disabling of the automatic
>> updates, it should be doable in a couple of ways. Either by executing a
>> script placed in UserData during guest VM creation and initialisation
>> or by manipulating elements (for example, such as we have a script placed
>> in *ubuntu-common* element that disables privacy extensions for IPv6
>> (RFC4941):
>>
>>
>> /usr/local/lib/python3.6/dist-packages/diskimage_builder/elements/ubuntu-common/install.d/80-disable-rfc3041
>>
>
> You are right, but the recommended way is either those changes could be
> contributed back to the upstream if they are common feature requests and
> could benefit the others, or they are implemented in a separate element so
> there is little chance that conflict may happen when upgrading trove.
>
>
>> I am really looking forward to our soon deployment of the Trove project,
>> i see huge potential there!
>>
>
> Good luck and please let me know if you have any other questions.
>
> ---
> Lingxian Kong
> Senior Cloud Engineer (Catalyst Cloud)
> Trove PTL (OpenStack)
> OpenStack Cloud Provider Co-Lead (Kubernetes)
> <http://www.catalystcloud.nz>
>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210216/1577eb8f/attachment-0001.html>


More information about the openstack-discuss mailing list