Open Stack

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.

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.