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 understands and interacts with
through the API.
Frankly, I believe all of these types of services should be built as
applications that run on OpenStack (or other) infrastructure. In other
words, they should not be part of the infrastructure itself.
There's really no need for a user of a DBaaS to have access to the
host or hosts the DB is running on. If the user really wanted that,
they would just spin up a VM/baremetal server and install the thing
themselves.
Yes, I think this area is where some hard thinking would be rewarded. I
recall when I first met Trove, in my mind I expected to be 'carving off
a piece of database'...and was a bit surprised to discover that it
(essentially) leveraged Nova VM + OS + DB (no criticism intended - just
saying I was surprised).
I think this is a common mistake (I know I've made it with respect to
other services) when hearing about a new *aaS thing and making
assumptions about the architecture. Here's a helpful way to think about it:
A cloud service has to have robust multitenancy. In the case of DBaaS,
that gives you two options. You can start with a database that is
already multitenant. If that works for your users, great. But many users
just want somebody else to manage $MY_FAVOURITE_DATABASE that is not
multitenant by design. Your only real option in that case is to give
them their own copy and isolate it somehow from everyone else's. This is
the use case that RDS and Trove are designed to solve.
It's important to note that this hasn't changed and isn't going to
change in the foreseeable future. What *has* changed is that there are
now more options for "isolate it somehow from everyone else's" - e.g.
you can use a container instead of a VM.
Of course after delving into how it worked I
realized that it did make sense to make use of the various Nova things
(schedulers etc)....
Fun fact: Trove started out as a *complete fork* of Nova(!).
*but* now we are thinking about re-architecting
(plus more options exist now), it would make sense to revisit this area.
__________________________________________________________________________
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
