Thanks for the info. Can you give a summary for reasons for why this was not a viable approach?
Tim From: Amrith Kumar <amrith.ku...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Tuesday, 15 August 2017 at 23:09 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@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.b...@cern.ch<mailto:tim.b...@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.ku...@gmail.com<mailto:amrith.ku...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, 15 August 2017 at 17:44 To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
