<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hi Dominic,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Although I'm not going to contribute to the Trove project anymore, I disagree with what you said that using database containers is a bad example, especially considering the project situation in the open source community in the past several years.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I've explained this several times to different people when I was making the change, but I don't mind repeating myself.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Trove was supporting multiple datastores previously and maintaining a bunch of DIB image elements to build different guest images. However, the task of keeping those elements up to date is not easy, and needs the domain knowledge of the specific database, but most of the active contributors have left and the project itself was on the edge of death.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">It was that time when I picked up the project because the database-as-a-service was on the service roadmap of our openstack based public cloud. Given this is such a complicated project with such a small team, it's impossible to maintain those different kinds of datastores. As a result, I made the decision to simplify the trove guest image build process and introduce container based database inside trove guest instance, so the project only needs to maintain a single common guest image but to support as more datastores as possible, offloading the database container image maintenance work to other upstream teams who specialize in the database technology area.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I don't think we had other better choices at that time.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Anyway, hope there will be more people could see my comment here and there will be someone raises his hand to lead this project forward. I'm glad to know Trove is deployed in your cloud, it's a pity that I didn't see any contribution coming from the team behind your cloud.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="color:rgb(102,102,102);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(102,102,102);font-family:monospace,monospace">---</span><br></div><div><font color="#666666" face="monospace, monospace">Lingxian Kon<span class="gmail_default" style="font-family:verdana,sans-serif">g</span></font></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 12, 2022 at 7:24 AM <<a href="mailto:DHilsbos@performair.com">DHilsbos@performair.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In Victoria, Trove moved to Docker images for the datastores.  Any datastores that didn't update themselves were removed, regardless of state.  I believe the only datastores currently supported are MariaDB, and PostgreSQL, though MySQL might be supported as well.<br>
<br>
Personally. I find this to have been a bad example of the "containerize all the things" mentality.  Trove now deploys an instance (vm) for each datastore instance, running a single container.  The exception is if you request backups, in which case a backup container is added to the instance (vm).<br>
<br>
Trove is installed in our OpenStack cloud, but we don't use it.<br>
<br>
Thank you,<br>
<br>
Dominic L. Hilsbos, MBA<br>
Vice President - Information Technology<br>
Perform Air International Inc.<br>
DHilsbos@PerformAir.com<br>
<a href="http://www.PerformAir.com" rel="noreferrer" target="_blank">www.PerformAir.com</a><br>
<br>
<br>
From: Ришат Азизов [mailto:<a href="mailto:rishat.azizov@gmail.com" target="_blank">rishat.azizov@gmail.com</a>] <br>
Sent: Sunday, February 6, 2022 11:10 AM<br>
To: <a href="mailto:openstack-discuss@lists.openstack.org" target="_blank">openstack-discuss@lists.openstack.org</a><br>
Subject: OpenStack Trove experimental datastores<br>
<br>
Hello!<br>
<br>
Why were the experimental datastores removed in the Trove OpenStack Victoria release? <a href="https://review.opendev.org/c/openstack/trove/+/728419" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/trove/+/728419</a><br>
<br>
Thanks!<br>
<br>
</blockquote></div></div>