Open Stack

Tim,

 

Sorry for the delay getting back to you.

 

Different database vendors give you different levels of isolation within your database itself, and making a database truly multi-tenant was something that we did not want to get into. The discussion centered around the benefits of such a use-case and thing that drove the decision to not go down the path of multi-tenancy was that if Trove provided a VM per database instance, implementing multi-tenancy is something that a trove user can in fact do for themselves.

 

At the time when we thought about this, the critical things on the horizon were to implement replication and clustering, and add support for more capabilities and databases. Therefore multi-tenancy did not rise very far on the list. 

 

Looking at it again, I like the idea but again think there are higher priority things I’d like to focus on first. In digging us out of the current ditch that we are in, multi-tenancy may not be the thing that would materially benefit the project.

 

But, we shall discuss in a week or so at PTG.

 

--

Amrith Kumar
amrith.kumar at gmail.com <mailto:amrith.kumar at gmail.com> 



 

From: Tim Bell [mailto:Tim.Bell at cern.ch] 
Sent: Wednesday, August 16, 2017 1:45 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

 

 

Thanks for the info.

 

Can you give a summary for reasons for why this was not a viable approach?

 

Tim

 

From: Amrith Kumar <amrith.kumar at gmail.com <mailto:amrith.kumar at gmail.com> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> >
Date: Tuesday, 15 August 2017 at 23:09
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> >
Subject: Re: [openstack-dev] [trove][tc][all] Trove restart - next steps

 

Tim,

This is an idea that was discussed at a trove midcycle a long time back (Juno midcycle, 2014). It came up briefly in the Kilo midcycle as well but was quickly rejected again.

I've added it to the list of topics for discussion at the PTG. If others want to add topics to that list, the etherpad is at https://etherpad.openstack.org/p/trove-queens-ptg​

 

Thanks!


-amrith

 

On Tue, Aug 15, 2017 at 12:43 PM, Tim Bell <Tim.Bell at cern.ch <mailto:Tim.Bell at cern.ch> > wrote:

One idea I found interesting from the past discussion was the approach that the user need is a database with a connection string.

 

How feasible is the approach where we are provisioning access to a multi-tenant database infrastructure rather than deploying a VM with storage and installing a database?

 

This would make the service delivery (monitoring, backup, upgrades) in the responsibility of the cloud provider rather than the end user. Some quota/telemetry would be needed to allocate costs to the project.

 

Tim

 

From: Amrith Kumar <amrith.kumar at gmail.com <mailto:amrith.kumar at gmail.com> >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> >
Date: Tuesday, 15 August 2017 at 17:44
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> >
Subject: [openstack-dev] [trove][tc][all] Trove restart - next steps

 

Now that we have successfully navigated the Pike release and branched
the tree, I would like to restart the conversation about how to revive
and restart the Trove project.

Feedback from the last go around on this subject[1] resulted in a
lively discussion which I summarized in [2]. The very quick summary is
this, there is interest in Trove, there is a strong desire to maintain
a migration path, there is much that remains to be done to get there.

What didn't come out of the email discussion was any concrete and
tangible uptick in the participation in the project, promises
notwithstanding.

There have however been some new contributors who have been submitting
patches and to help channel their efforts, and any additional
assistance that we may receive, I have created the (below) list of
priorities for the project. These will also be the subject of
discussion at the PTG in Denver.

   - Fix the gate

       - Update currently failing jobs, create xenial based images
       - Fix gate jobs that have gone stale (non-voting, no one paying
         attention)

   - Bug triage

       - Bugs in launchpad are really out of date, assignments to
         people who are no longer active, bugs that are really support
         requests, etc.,
       - Prioritize fixes for Queens and beyond

   - Get more active reviewers

       - There seems to still be a belief that 'contributing' means
         'fixing bugs'. There is much more value in actually doing
         reviews.
       - Get at least a three member active core review team by the
         end of the year.

   - Complete Python 3 support

      - Currently not complete; especially on the guest side

   - Community Goal, migrate to oslo.policy

   - Anything related to new features

This is clearly an opinionated list, and is open to change but I'd
like to do that based on the Agile 'stand up' meeting rules. You know, the chicken and pigs thing :)

So, if you'd like to get on board, offer suggestions to change this
list, and then go on to actually implement those changes, c'mon over.

-amrith



[1] http://openstack.markmail.org/thread/wokk73ecv44ipfjz
[2] http://markmail.org/message/gfqext34xh5y37ir


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170903/bfdaadc3/attachment.html>