Open Stack

Yeah, if there is a way to test SQL Server integration for Trove in
upstream CI, either using Developer Edition or 3rd party CI facility, I
don't see there is any reason to block the contribution

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


On Wed, Feb 17, 2021 at 12:08 AM Bekir Fajkovic <
bekir.fajkovic at citynetwork.eu> wrote:

> Hello!
>
> Yes, i am aware of the fact that MSSQL was previously provisioned only
> through a certain forks derived from the Trove project, prior to Victoria
> release, that's true.
>
> I assume You are aiming at licensing and cost issues in regards of testing
> and usage in general of the mssql as an enterprise platform?
>
> My vision is like this - there are already docker images ready for
> deployment of mssql 2017 and 2019 versions (all editions, Developer -
> Express - Standard - Enterprise - EnterpriseCore)
> and these are available for docker deployment through environment
> variables (MSSQL_PID in particular) where the product id is the edition
> chosen. If choosing a commercial edition,
> Microsoft assumes the SPLA or other license agreement already exists for
> the customer, so the pricing for the commercial  instances should easily be
> figured out by the cloud hosting
> platform and existing license agreements with Microsoft. It is at least so
> if You try to deploy mssql on, say, Ubuntu today. After installation, user
> must execute a script that configures
> certain things and also deploys the suitable Edition chosen (and the
> license model as well). No need fot any license key registration is needed
> in this kind of scenario.
>
> When it comes to testing, Developer Edition of the product would be quite
> suitable since it is free of charge. Express Edition is free of charge as
> well but Developer Edition provides full functionality.
> Pure functionality testing can be carried out by, say, at least City
> Network, each time new things are deployed and improved for that particular
> datastore type.
>
> Honestly, although not open source and although it is highly commercial
> product, a huge army of the customers are expecting mostly that particular
> database type to be provided.
>
> :)
>
> *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: 02/16/21 11:33
> To: Bekir Fajkovic (bekir.fajkovic at citynetwork.eu)
> Cc: openstack-discuss (openstack-discuss at lists.openstack.org)
> Subject: Re: Re[4]: Some questions regarding OpenStack Trove Victoria
> release
>
> 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/20210217/5f3e9fbd/attachment.html>