On Wed, Jun 21, 2017 at 1:52 AM, Thierry Carrez <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
