[openstack-dev] [trove][tc][all] Trove restart - next steps

Tim Bell Tim.Bell at cern.ch
Wed Aug 16 17:44:53 UTC 2017


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>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <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>
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/20170816/1b9f0bd4/attachment.html>


More information about the OpenStack-dev mailing list