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

Davanum Srinivas davanum at gmail.com
Wed Jun 21 13:42:15 UTC 2017


On Wed, Jun 21, 2017 at 1:52 AM, Thierry Carrez <thierry at openstack.org> 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 proposed solution for the *aaS
>> services from many moons ago) vs. decoupling it from OpenStack in
>> general so that the operator has more flexibility in how to deploy.
>>
>> I'd love to be able to cover both - from a user using it standalone to
>> spin up and manage a DB in containers on a shared PaaS, through to a
>> user accessing it as a service to provide a DB running on a dedicated VM
>> or bare metal server, and everything in between. I don't know is such a
>> thing is feasible. I suspect we're going to have to talk a lot about VMs
>> and network plumbing and volume storage :)
>
> As another data point, we are seeing this very same tradeoff with Magnum
> vs. Tessmaster (with "I want to get a Kubernetes cluster" rather than "I
> want to get a database").
>
> Tessmaster is the user-side tool from EBay deploying Kubernetes on
> different underlying cloud infrastructures: takes a bunch of cloud
> credentials, then deploys, grows and shrinks Kubernetes cluster for you.
>
> Magnum is the infrastructure-side tool from OpenStack giving you
> COE-as-a-service, through a provisioning API.
>
> Jay is advocating for Trove to be more like Tessmaster, and less like
> Magnum. I think I agree with Zane that those are two different approaches:
>
> From a public cloud provider perspective serving lots of small users, I
> think a provisioning API makes sense. The user in that case is in a
> "black box" approach, so I think the resulting resources should not
> really be accessible as VMs by the tenant, even if they end up being
> Nova VMs. The provisioning API could propose several options (K8s or
> Mesos, MySQL or PostgreSQL).

I like this! ^^ If we can pull off "different underlying cloud
infrastructures" like TessMaster, that would be of more value to folks
who may not be using OpenStack (or VMs!)


>
> From a private cloud / hybrid cloud / large cloud user perspective, the
> user-side deployment tool, letting you deploy the software on various
> types of infrastructure, probably makes more sense. It's probably more
> work to run it, but you gain in flexibility. That user-side tool would
> probably not support multiple options, but be application-specific.
>
> So yes, ideally we would cover both. Because they target different
> users, and both are right...
>
> --
> Thierry Carrez (ttx)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims



More information about the OpenStack-dev mailing list