Open Stack

On Tue, Nov 15, 2016 at 8:56 AM, Monty Taylor <mordred at inaugust.com> wrote:
> The auth story. The native/default auth for gRPC is oauth. It has the
> ability for pluggable auth, but that would raise the barrier for new
> languages. I'd love it if we can come up with a story that involves
> making API users in keystone and authorizing them to use oaktree via an
> oauth transaction. The keystone auth backends currently are all about
> integrating with other auth management systems, which is great for
> environments where you have a web browser, but not so much for ones
> where you need to put your auth credentials into a file so that your
> scripts can work. I'm waving my hands wildly here - because all I really
> have are problems to solve and none of the solutions I have are great.

I think it is very important to not introduce new concepts to the gRPC
model here, ie, not require any out-of-band auth, such as getting a
token directly from Keystone before making any gRPC calls.

> Glance Image Uploads and Swift Object Uploads (and downloads). Having
> those two data operations go through an API proxy seems inefficient.
> However, having them not in the API seems like a bad user experience.
> Perhaps if we take advantage of the gRPC streaming protocol support
> doing a direct streaming passthrough actually wouldn't be awful. Or
> maybe the better approach would be for the gRPC call to return a URL and
> token for a user to POST/PUT to directly. Literally no clue.

Looking back at my notes from the Image v2 create talks, we have the
opportunity to finally get this right, so let's take the time to do
that.

One thing I think is worthwhile to point out is that (at this point
anyway) there is nothing here that requires 'insider' knowledge of a
cloud deployment to use oaktree, ie it does not have to be deployed by
the cloud operator.  You could run your own oaktree in front of
$PUBLIC_CLOUD and/or $PRIVATE_CLOUD.

dt

-- 

Dean Troyer
dtroyer at gmail.com