Open Stack

Good discussion, Zane. Comments inline.

On 06/20/2017 11:01 AM, Zane Bitter wrote:
> On 20/06/17 10: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.
> 
> Hey Jay,
> I'd be interested in exploring this idea with you, because I think 
> everyone agrees that this would be a good goal, but at least in my mind 
> it's not obvious what the technical solution should be. (Actually, I've 
> read your email a bunch of times now, and I go back and forth on which 
> one you're actually advocating for.) The two options, as I see it, are 
> as follows:
> 
> 1) The database VMs are created in the user's tena^W project. They 
> connect directly to the tenant's networks, are governed by the user's 
> quota, and are billed to the project as Nova VMs (on top of whatever 
> additional billing might come along with the management services). A 
> [future] feature in Nova (https://review.openstack.org/#/c/438134/) 
> allows the Trove service to lock down access so that the user cannot 
> actually interact with the server using Nova, but must go through the 
> Trove API. On a cloud that doesn't include Trove, a user could run Trove 
> as an application themselves and all it would have to do differently is 
> not pass the service token to lock down the VM.
> 
> alternatively:
> 
> 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.

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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev