There already is a user side tools for deploying plumbing onto your own cloud. stuff like Tessmaster itself.
I think the win is being able to extend that k8s with the ability to declaratively request database clusters and manage them. Its all about the commons. 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 orchestration engine that's already cross cloud that can be easily deployed by user or cloud operator, and fill in the gaps with what Trove wants to support, easy management of db's, you get to reuse a lot of the commons and the users slight increase in investment in dealing with the bit of extra plumbing in there allows other things to also be easily added to their cluster. Its very rare that a user would need to deploy/manage only a database. The net load on the operator decreases, not increases. Look at helm apps for some examples. They do complex web applications that have web tiers, database tiers, etc. But they currently suffer from lack of good support for clustered databases. In the end, the majority of users care about helm install my_scalable_app kind of things rather then installing all the things by hand. Its a pain. OpenStack itself has this issue. It has lots of an api tiers and a db tiers. If Trove was a k8s operator, OpenStack on k8s 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 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 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). 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-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
