Open Stack

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)





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210216/a6791d89/attachment-0001.html>