<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 15, 2016 at 5:16 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Awesome start, Monty :) Comments inline.<span class=""><br>
<br>
On 11/15/2016 09:56 AM, Monty Taylor wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey everybody!<br>
<br>
At this past OpenStack Summit the results of the Interop Challenge were<br>
shown on stage. It was pretty awesome - 17 different people from 17<br>
different clouds ran the same workload. And it worked!<br>
<br>
However, one of the reasons it worked is because they all used the<br>
Ansible modules we wrote that are based on the shade library that<br>
contains the business logic needed to hide vendor differences in clouds.<br>
That means that there IS a fantastic OpenStack interoperability story -<br>
but only if you program in Python. That's less awesome.<br>
<br>
With that in mind - I'm pleased to announce a new project that aims to<br>
address that - oaktree.<br>
<br>
oaktree is a gRPC-based API porcelain service for OpenStack that is<br>
based on the shade library and I'd love some help in writing it.<br>
<br>
Basing oaktree on shade gets not only the business logic. Shade already<br>
understands a multi-cloud world. And because we use shade in Infra for<br>
nodepool, it already has caching, batching and thundering herd<br>
protection sorted to be able to hand very high loads efficiently. So<br>
while oaktree is new, the primary logic and fundamentals are all shade<br>
and are battle-tested.<br>
</blockquote>
<br></span>
++ muy bueno.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The barrier to deployers adding it to their clouds needs to be as low as<br>
humanly possible. So as we work on it, ensuring that we keep it<br>
dead-simple to install, update and operate must be a primary concern.<br>
<br>
Where are we and what's next?<br>
<br>
oaktree doesn't do a whole lot that's terribly interesting at the<br>
moment. We have all of the development scaffolding and gate jobs set up<br>
and a few functions implemented.<br>
<br>
oaktree exists currently as two repos - oaktree and oaktreemodel:<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/oaktree" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/oaktree</a><br>
<a href="http://git.openstack.org/cgit/openstack/oaktreemodel" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/oaktreemodel</a><br>
<br>
oaktreemodel contains the Protobuf definitions and the build scripts to<br>
produce Python, C++ and Go code from them. The python code is published<br>
to PyPI as a normal pure-python library. The C++ code is published as a<br>
source tarball and the Go code is checked back in to the same repo so<br>
that go works properly.<br>
</blockquote>
<br></span>
Very nice. I recently started playing around with gRPC myself for some ideas I had about replacing part of nova-compute with a Golang worker service that can tolerate lengthy disconnections with a centralized control plane (hello, v[E]CPE!).<br>
<br>
It's been (quite) a few years since I last used protobufs (hey, remember Drizzle?) but it's been a blast getting back into protobufs development. Now that I see you're using a similar approach for oaktree, I'm definitely interested in contributing.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
oaktree depends on the python oaktreemodel library, and also on shade.<br>
It implements the server portion of the gRPC service definition.<br>
<br>
Currently, oaktree can list and search for flavors, images and floating<br>
ips. Exciting right? Most of the work to expose the rest of the API that<br>
shade can provide at the moment is going to be fairly straightforward -<br>
although in each case figuring out the best mapping will take some care.<br>
<br>
We have a few major things that need some good community design. These<br>
are also listed in a todo.rst file in the oaktree repo which is part of<br>
the docs:<br>
<br>
<a href="http://oaktree.readthedocs.io/en/latest/" rel="noreferrer" target="_blank">http://oaktree.readthedocs.io/<wbr>en/latest/</a><br>
<br>
The auth story. The native/default auth for gRPC is oauth. It has the<br>
ability for pluggable auth, but that would raise the barrier for new<br>
languages. I'd love it if we can come up with a story that involves<br>
making API users in keystone and authorizing them to use oaktree via an<br>
oauth transaction.<br>
</blockquote>
<br></span>
++<span class=""><br>
<br>
> The keystone auth backends currently are all about<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
integrating with other auth management systems, which is great for<br>
environments where you have a web browser, but not so much for ones<br>
where you need to put your auth credentials into a file so that your<br>
scripts can work. I'm waving my hands wildly here - because all I really<br>
have are problems to solve and none of the solutions I have are great.<br>
<br>
Glance Image Uploads and Swift Object Uploads (and downloads). Having<br>
those two data operations go through an API proxy seems inefficient.<br>
</blockquote>
<br></span>
Uh, yeah :)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, having them not in the API seems like a bad user experience.<br>
Perhaps if we take advantage of the gRPC streaming protocol support<br>
doing a direct streaming passthrough actually wouldn't be awful. Or<br>
maybe the better approach would be for the gRPC call to return a URL and<br>
token for a user to POST/PUT to directly. Literally no clue.<br>
<br>
In any case - I'd love help from anyone who thinks this sounds like a<br>
good idea. In a perfect world we'll have something ready for 1.0 by Atlanta.<br>
</blockquote>
<br></span>
I'll try my best to dig into the code this week/end.<br>
<br>
Best,<br>
-jay<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Join us in #openstack-shade if you want to hack.<br>
<br>
Thanks!<br>
Monty<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">You know I'm going to be diving back into this. There are some challenges we've already talked about when it comes to Shade->OakTree and OakTree->OakTree type of communications.</div><div class="gmail_extra"><br></div><div class="gmail_extra">--Morgan</div></div>