Open Stack

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