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
<magic>, and isolated from other users' databases running in the same
project through <security groups? hierarchical projects? magic?>.
Trove has its own quota management and billing. The user cannot
interact with the server using Nova since it is owned by a different
project. On a cloud that doesn't include Trove, a user could run Trove
as an application themselves, by giving it credentials for their own
project and disabling all of the cross-tenant networking stuff.
None of the above :)
Don't think about VMs at all. Or networking plumbing. Or volume storage
or any of that.
Think only in terms of what a user of a DBaaS really wants. At the end
of the day, all they want is an address in the cloud where they can
point their application to write and read data from.
Do they want that data connection to be fast and reliable? Of course,
but how that happens is irrelevant to them
Do they want that data to be safe and backed up? Of course, but how that
happens is irrelevant to them.
Hi, I'm just newb trying to follow along...isnt that what #2 is
proposing? just it's talking about the implementation a bit.
(Guess this comes down to the terms "user" and "operator" - e.g.
"operator" has the VMs w/ the DBs, "user" gets a login to a DB. "user"
is the person who pushes the trove button to "give me a database")
The problem with many of these high-level *aaS projects is that they
consider their user to be a typical tenant of general cloud
infrastructure -- focused on launching VMs and creating volumes and
networks etc. And the discussions around the implementation of these
projects always comes back to minutia about how to set up secure
communication channels between a control plane message bus and the
service VMs.
If you create these projects as applications that run on cloud
infrastructure (OpenStack, k8s or otherwise), then the discussions focus
instead on how the real end-users -- the ones that actually call the
APIs and utilize the service -- would interact with the APIs and not the
underlying infrastructure itself.
Here's an example to think about...
What if a provider of this DBaaS service wanted to jam 100 database
instances on a single VM and provide connectivity to those database
instances to 100 different tenants?
Would those tenants know if those databases were all serviced from a
single database server process running on the VM? Or 100 contains each
running a separate database server process? Or 10 containers running 10
database server processes each?
No, of course not. And the tenant wouldn't care at all, because the
point of the DBaaS service is to get a database. It isn't to get one or
more VMs/containers/baremetal servers.
At the end of the day, I think Trove is best implemented as a hosted
application that exposes an API to its users that is entirely separate
from the underlying infrastructure APIs like Cinder/Nova/Neutron.
This is similar to Kevin's k8s Operator idea, which I support but in a
generic fashion that isn't specific to k8s.
In the same way that k8s abstracts the underlying infrastructure (via
its "cloud provider" concept), I think that Trove and similar projects
need to use a similar abstraction and focus on providing a different API
to their users that doesn't leak the underlying infrastructure API
concepts out.
Best,
-jay
Of course the current situation, as Amrith alluded to, where the
default is option (1) except without the lock-down feature in Nova,
though some operators are deploying option (2) but it's not tested
upstream... clearly that's the worst of all possible worlds, and AIUI
nobody disagrees with that.
To my mind, (1) sounds more like "applications that run on OpenStack
(or other) infrastructure", since it doesn't require stuff like the
admin-only cross-project networking that makes it effectively "part of
the infrastructure itself" - as evidenced by the fact that
unprivileged users can run it standalone with little more than a
simple auth middleware change. But I suspect you are going to use
similar logic to argue for (2)? I'd be interested to hear your thoughts.
cheers,
Zane.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
