Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Doug, I agree, VM/baremetal, shared VM, object for backup storage or block device for backup storage, those are implementation choices. We should not have quota/billing depend on those; Trove should expose counters and space-time-products of the things that Trove users should be billed for. At

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove Kevin, In interests of 'keeping it simple', I'm going to try and prioritize the use-cases and pick implementation strategies which target the higher priority ones without

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

re quota then the hosts can actually > handle. > > Thanks, > Kevin > > From: Doug Hellmann [d...@doughellmann.com] > Sent: Wednesday, July 12, 2017 6:57 AM > To: openstack-dev > Subject: Re: [openstack-dev] [trove][all][tc] A pr

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove Excerpts from Amrith Kumar's message of 2017-07-12 06:14:28 -0500: > All: > > First, let me thank all of you who responded and provided feedback > on what I wrote. I've summarized what I heard below an

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Excerpts from Amrith Kumar's message of 2017-07-12 06:14:28 -0500: > All: > > First, let me thank all of you who responded and provided feedback > on what I wrote. I've summarized what I heard below and am posting > it as one consolidated response rather than responding to each > of your messages

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

All: First, let me thank all of you who responded and provided feedback on what I wrote. I've summarized what I heard below and am posting it as one consolidated response rather than responding to each of your messages and making this thread even deeper. As I say at the end of this email, I will

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

stack-dev@lists.openstack.org> > Date:06/18/2017 06:41 AM > Subject:[openstack-dev] [trove][all][tc] A proposal to > rearchitect Trove > -- > > > > Trove has evolved rapidly over the past several years, since integrati

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

.ku...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 06/18/2017 06:41 AM Subject: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove Trove has evolved rapidly over the pas

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

isagree with the goal of being able to rely on Kubernetes for >> many things. But relying on Kubernetes doesn't solve the "I want some >> easy-to-install infrastructure" problem. Nor does it solve the types of >> advanced networking scenarios that the NFV communit

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

ersation going. ​ > > Thanks, > Kevin > ________ > From: Jay Pipes [jaypi...@gmail.com] > Sent: Thursday, June 22, 2017 10:05 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchite

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

: Thursday, June 22, 2017 12:58 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove Fox, Kevin M wrote: [...] If you build a Tessmaster clone just to do mariadb, then you share nothing with the other communities and have to reinvent

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 23/06/17 05:31, Thierry Carrez wrote: Zane Bitter wrote: But back in the day we had a process (incubation) for adding stuff to OpenStack that it made sense to depend on being there. It was a highly imperfect process. We got rid of that process with the big tent reform, but didn't really

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Zane Bitter wrote: > But back in the day we had a process (incubation) for adding stuff to > OpenStack that it made sense to depend on being there. It was a highly > imperfect process. We got rid of that process with the big tent reform, > but didn't really replace it with anything at all. Tags

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

OpenStack ecosystem. Fewer deps. Do one thing well. Solid APIs." I don't think that the above leads to "further fracturing OpenStack". I think it leads to solid, reusable components. Best, -jay Thanks, Kevin ____ From: Thierry Carrez [thie

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

From: Jay Pipes [jaypi...@gmail.com] Sent: Thursday, June 22, 2017 10:05 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove On 06/22/2017 11:59 AM, Fox, Kevin M wrote: > My $0.02. > >

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

> -Original Message- > From: Zane Bitter [mailto:zbit...@redhat.com] > Sent: June-20-17 4:57 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect > Trove > > On 20/06/17 11:45, Jay Pipes wrote: &

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

tl;dr - I think Trove's successor has a future, but there are two conflicting ideas presented and Trove should pick one or the other. Excerpts from Amrith Kumar's message of 2017-06-18 07:35:49 -0400: > > We have learned a lot from v1, and the hope is that we can address that in > v2. Some of

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Stack". I think it leads to solid, reusable components. Best, -jay Thanks, Kevin From: Thierry Carrez [thie...@openstack.org] Sent: Thursday, June 22, 2017 12:58 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearch

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

; project collaboration for features. I fear the new push for letting > projects run standalone will make this worse, not better, further > fracturing OpenStack. > > Thanks, > Kevin > > From: Thierry Carrez [thie...@openstack.org] > Sent: Th

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Carrez [thie...@openstack.org] Sent: Thursday, June 22, 2017 12:58 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove Fox, Kevin M wrote: > [...] > If you build a Tessmaster clone just to do mariadb, then you share n

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Fox, Kevin M wrote: > [...] > If you build a Tessmaster clone just to do mariadb, then you share nothing > with the other communities and have to reinvent the wheel, yet again. > Operators load increases because the tool doesn't function like other tools. > > If you rely on a container

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

over k8s Third Party Resources (TPR) and would make Trove entirely > stateless. k8s maintains all state for everything in etcd. > > Please consider this architecture. > > Thanks, > Kevin > > ------------------ > *From:* Amrith Kumar [amrith.ku...@gmail.com] > *Sent:* Sunday, June 18, 2017 4:35

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

could use it to deploy the rest of OpenStack. Even more sharing. Thanks, Kevin From: Thierry Carrez [thie...@openstack.org] Sent: Wednesday, June 21, 2017 1:52 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][all][tc] A proposal

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 21/06/17 01:49, Mark Kirkwood wrote: On 21/06/17 02:08, Jay Pipes wrote: On 06/20/2017 09:42 AM, Doug Hellmann wrote: Does "service VM" need to be a first-class thing? Akanda creates them, using a service user. The VMs are tied to a "router" which is the billable resource that the user

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On Wed, Jun 21, 2017 at 1:52 AM, Thierry Carrez wrote: > Zane Bitter wrote: >> [...] >> Until then it seems to me that the tradeoff is between decoupling it >> from the particular cloud it's running on so that users can optionally >> deploy it standalone (essentially Vish's

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Zane Bitter wrote: > [...] > Until then it seems to me that the tradeoff is between decoupling it > from the particular cloud it's running on so that users can optionally > deploy it standalone (essentially Vish's proposed solution for the *aaS > services from many moons ago) vs. decoupling it

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 21/06/17 02:08, Jay Pipes wrote: On 06/20/2017 09:42 AM, Doug Hellmann wrote: Does "service VM" need to be a first-class thing? Akanda creates them, using a service user. The VMs are tied to a "router" which is the billable resource that the user understands and interacts with through the

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 20/06/17 11:45, Jay Pipes wrote: Good discussion, Zane. Comments inline. ++ On 06/20/2017 11:01 AM, Zane Bitter wrote: On 20/06/17 10:08, Jay Pipes wrote: On 06/20/2017 09:42 AM, Doug Hellmann wrote: Does "service VM" need to be a first-class thing? Akanda creates them, using a

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Excerpts from Jay Pipes's message of 2017-06-20 10:08:54 -0400: > On 06/20/2017 09:42 AM, Doug Hellmann wrote: > > Does "service VM" need to be a first-class thing? Akanda creates > > them, using a service user. The VMs are tied to a "router" which > > is the billable resource that the user

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 06/20/2017 11:45 AM, Jay Pipes wrote: Good discussion, Zane. Comments inline. On 06/20/2017 11:01 AM, Zane Bitter wrote: 2) The database VMs are created in a project belonging to the operator of the service. They're connected to the user's network through , and isolated from other

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Good discussion, Zane. Comments inline. On 06/20/2017 11:01 AM, Zane Bitter wrote: On 20/06/17 10:08, Jay Pipes wrote: On 06/20/2017 09:42 AM, Doug Hellmann wrote: Does "service VM" need to be a first-class thing? Akanda creates them, using a service user. The VMs are tied to a "router"

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 20/06/17 10:08, Jay Pipes wrote: On 06/20/2017 09:42 AM, Doug Hellmann wrote: Does "service VM" need to be a first-class thing? Akanda creates them, using a service user. The VMs are tied to a "router" which is the billable resource that the user understands and interacts with through the

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 18/06/17 07:35, Amrith Kumar wrote: Trove has evolved rapidly over the past several years, since integration in IceHouse when it only supported single instances of a few databases. Today it supports a dozen databases including clusters and replication. The user survey [1] indicates that

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 06/20/2017 09:42 AM, Doug Hellmann wrote: Does "service VM" need to be a first-class thing? Akanda creates them, using a service user. The VMs are tied to a "router" which is the billable resource that the user understands and interacts with through the API. Frankly, I believe all of these

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Excerpts from Curtis's message of 2017-06-19 18:56:25 -0600: > On Sun, Jun 18, 2017 at 5:35 AM, Amrith Kumar wrote: > > Trove has evolved rapidly over the past several years, since integration in > > IceHouse when it only supported single instances of a few databases.

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 19/06/17 20:56, Curtis wrote: I really think the concept of "service VMs" should be a thing. I'm not sure where the OpenStack community has landed on that, my fault for not paying close attention, but we should be able to create VMs for a tenant that are not managed by the tenant but that

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On 20/06/17 12:56, Curtis wrote: > On Sun, Jun 18, 2017 at 5:35 AM, Amrith Kumar wrote: >> Trove has evolved rapidly over the past several years, since integration in >> IceHouse when it only supported single instances of a few databases. Today >> it supports a dozen

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

On Sun, Jun 18, 2017 at 5:35 AM, Amrith Kumar wrote: > Trove has evolved rapidly over the past several years, since integration in > IceHouse when it only supported single instances of a few databases. Today > it supports a dozen databases including clusters and

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Amrith, Some good thoughts in your email. I've replied to a few specific pieces below. Overall I think it's a good start to a plan. On Sun, Jun 18, 2017 at 5:35 AM, Amrith Kumar wrote: > Trove has evolved rapidly over the past several years, since integration > in

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Kevin From: Amrith Kumar [amrith.ku...@gmail.com] Sent: Sunday, June 18, 2017 4:35 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove Trove has evolved rapidly over the past several years,

Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Amrith Kumar wrote: > [...] > An important aspect of making this proposal work is that we seek to > eliminate the effort (planning, and coding) involved in migrating > existing Trove v1 deployments to the proposed Trove v2. Effectively, > with work beginning on Trove v2 as proposed here, Trove v1

[openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

Trove has evolved rapidly over the past several years, since integration in IceHouse when it only supported single instances of a few databases. Today it supports a dozen databases including clusters and replication. The user survey [1] indicates that while there is strong interest in the