Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Clint Byrum]

Excerpts from Zane Bitter's message of 2016-11-21 15:12:45 -0500:
> On 18/11/16 16:47, Clint Byrum wrote:
> > Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
> >> On 15/11/16 09:56, Monty Taylor wrote:
> > I know Monty said this, but I want to say it again: gRPC is just HTTP/2
> > + protobufs. Meaning, it's available to virtually every programming
> > language in wide usage at this time (the limiting factor being protobuf
> > implementatoins):
> >
> > https://github.com/google/protobuf/blob/master/docs/third_party.md
> 
> I get that, but what I'm spending a lot of my time on is interactions 
> between OpenStack components, and that uses the OpenStack APIs because.. 
> well because they're the OpenStack APIs.
> 
> So maybe in the event of a failure occurring somewhere I want to spin up 
> some replacement resources, and then put things back how they were again 
> later, using a Mistral workflow. And say that oaktree will magically fix 
> some cross-cloud interop differences for me when I first spin up my app. 
> Now I'm faced with a bad choice: either I have to replicate the magic in 
> a second language, because OpenStack doesn't speak shade/oaktree, or I 
> have to give up on the magic and just implement everything myself, or I 
> have to give up on the idea of doing anything especially interesting at 
> runtime and hope my app just keeps working as deployed, or I have to 
> give up on ever deploying my app on more than one cloud.
> 
> The only thing that will avoid _all_ of those bad choices, and I realise 
> I am preaching to the choir here, is if we fix the APIs such that they 
> don't *need* magic to work well across clouds.
> 

So now that I understand what you're saying.. a pragmatic solution to
this might be to have Mistral and Heat use shade instead of the native
clients. An idealistic solution would be to start pushing the projects
to hide their implementation details better.

> >> I feel like the entire OpenStack project has, out of a desire not to be
> >> opinionated, consistently failed both our users and operators by
> >> encouraging all sorts of unnecessarily incompatible configurations. Not
> >> to pick on any particular project but e.g. can anyone tell me why
> >> Neutron doesn't automatically come, out of the box, with external
> >> networks called "internet" and "openstack" so that users can create
> >> floating IPs that talk to either the internet or just the control plane,
> >> respectively, on any OpenStack cloud with a single Heat template (or
> >> whatever) without having to paste UUIDs anywhere? What sane reason could
> >> there be to even allow, let alone force, all operators to solve these
> >> problems independently?
> >>
> >
> > Side note: As of right now, I'm pretty sure the only place where you
> > should have to use network UUID's pasted somewhere is Octavia.
> >
> > Also, many OpenStack clouds are not on the internet, and do not want to
> > give instances access to the control plane. So your example perhaps
> > needs more thought.
> 
> I'm not saying that you have to supply any IP addresses to the pool. 
> Just that only the wilfully contrary should call the internet anything 
> other than "internet", and that we should ensure this *in code* instead 
> of just hoping that everyone will coincidentally choose the same thing 
> (spoiler: they don't) so that both end users *and other OpenStack 
> projects* can rely on it.
> 
> (Also, the point of floating IPs with access to only the control plane 
> is not so instances can access the control plane; it's so that the 
> control plane can access the instances without everyone on the internet 
> - or whatever other external network you might connect to - necessarily 
> being able to do the same.)
> 

My point is that this is not cut and dry, and I think it deserves long,
hard thought. I _DO_ love the idea of having conventions which
application authors can begin to rely on.

> >> I'm sure the infra team can think of 100 pet annoyances like that. So
> >> carry on, but maybe y'all could make a list somewhere of all the
> >> interoperability problems that shade has had to work around and we could
> >> try to make it a priority as a community to address them?
> >>
> >
> > Shade is the python expression of those annoyances. Oaktree would be
> > exposing that as a gRPC API.
> 
> So what's the governance expression of those annoyances? :)
> 

I think community goals would be a way to address this. But we need to
first express exactly what we think is wrong with the API's now, and
then come up with a plan to normalize them. I believe the API WG and
Arch-WG might be good places to address this. The former, to address
the structure of each API, and the latter, to address the interactions
of the components.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

On 11/21/2016 03:36 PM, Zane Bitter wrote:
> On 18/11/16 16:56, Clint Byrum wrote:
>> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>>> So, say that I want to create my servers in Heat so that I can use Heat
>>> software deployments for orchestration. How would I go about e.g. making
>>> sure that the servers are always connected to the networks I expect on a
>>> variety of different clouds? Would Oaktree figure out the networks and
>>> pass them in to the stack when creating it? (I don't believe shade has
>>> Heat support yet, but we should definitely add it & I don't foresee any
>>> great obstacle.) Or would Heat have to add Oaktree resource types?
>>>
>>
>> If you're wanting to use Heat, you are a) already cutting off a large
>> quantity of interoperable clouds because many do not have Heat,
> 
> (Roughly one third, according to the user survey.) We have a mechanism
> to resolve that though (defcore), and I'm confident that that will
> happen in due course. I'm less confident that we have any mechanism for
> resolving these other questions.
> 
> Perhaps we could use defcore-required Tempest tests to drive alignment
> on some of those too. But we'd have to decide what we want to align on
> first.
> 
>> and b)
>> you already have provider templates to deal with the inconsistencies
>> across clouds.
> 
> Indeed, and environment files and conditionals as well.
> 
>> And Shade has had Heat support in some for or another for a long time:
>>
>> 9922cfbb(Monty Taylor   2015-12-03 18:12:32 -0500 32)import
>> heatclient.client
> 
> Oh, great! I knew it had been on the agenda for a while but I didn't
> know if it had actually happened or not, so I had a quick glance at
> http://docs.openstack.org/infra/shade/model.html and there was no mention.

Yah - the model documentation is new, and we're going through resource
by resource to make sure we've published exactly what attributes of what
resources we can commit to making sure are there, and which ones may or
may not be there based on underlying cloud differences.

>> To answer your other question, I don't think that's actually desirable or
>> realistic for interop expectations. If networking were one-size-fits-all
>> we wouldn't even need Neutron (we had a one-size-fits-all solution, it
>> was
>> nova-network). We have Neutron so you can construct what you need inside
>> the cloud.
> 
> I'd prefer that we treat Neutron as a way to construct a consistent set
> of abstractions that users can rely on to construct what they need,
> rather than a way to expose the implementation decisions of the operator
> to the user.
> 
> (Ditto for all OpenStack projects, actually.)

ZOMG yes.

>> Shade just normalizes the "how do I get to the instances from
>> outside the cloud" part, which has several different variants.
>>
>>> It sounds to me like the former approach would require all of the same
>>> work in the template that you'd need to handle it now (using
>>> conditionals), and the only real difference is that instead of providing
>>> your own environment file for each cloud you do a bit of oaktree
>>> integration and that figures it out for you instead.
>>>
>>> Adding Oaktree resource types to Heat to paper over isn't really a
>>> solution from my point of view.
>>>
>>
>> Agreed, Heat, to me, sits behind Oaktree and Shade, not in front of it.
>> Mostly just to avoid needing to grok Keystone and all of its glory.
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

On 11/21/2016 03:25 PM, Kevin Benton wrote:
>>I'm not saying that you have to supply any IP addresses to the pool.
> Just that only the wilfully contrary should call the internet anything
> other than "internet", and that we should ensure this *in code* instead
> of just hoping that everyone will coincidentally choose the same thing
> (spoiler: they don't) so that both end users *and other OpenStack
> projects* can rely on it.
> 
> A big chunk of enterprise deployments I see don't have real Internet IPs
> available as floating IPs, they are just IP addresses reachable from the
> whole company network. They are available everywhere they need for their
> use cases so all tooling they use can effectively treat them as
> "Internet" addresses (reachable from everywhere in their corporate
> network), but they are not the real Internet. 
> 
> So either you force them to lie and call it "internet" to work with
> tooling that expects that, or they can't use any tooling built on this
> new concept of "internet". Pick your poison.

Yah. In shade we refer to these as "external" and the docs say
"externally routable" - which more specifically means "able to route to
things that are not on this cloud". (this is because of the very thing
you mention.

In general, there are a few network constructs that seem to come up a
lot but can easily get lost in bikeshedding our way towards perfection:

* This network can route packets to things that are not on this cloud
* This network can provide IPs to be used for NAT
* This network can provide IPs that can be used directly
* This network can be the destination of NAT

Also, clouds frequently have one or more of the following network
connection policies:

* Route traffic in and out of the cloud via NAT
* Route traffic in and out of the cloud directly
* Only route traffic to other instances in this cloud

AND - as if those are not enough, there is also:

* This cloud has IPv4 and IPv6
* This cloud only has IPv4
* This cloud only has IPv6

Because you can combine all of those in any way you want, you can end up
with:

* This cloud has a network that will directly attach IPv6 addresses that
can route traffic in and out of the cloud but will attach IPv4 addresses
that require NAT to get in and out of the cloud.

> On Mon, Nov 21, 2016 at 12:12 PM, Zane Bitter  > wrote:
> 
> On 18/11/16 16:47, Clint Byrum wrote:
> 
> Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
> 
> On 15/11/16 09:56, Monty Taylor wrote:
> 
> Hey everybody!
> 
> At this past OpenStack Summit the results of the Interop
> Challenge were
> shown on stage. It was pretty awesome - 17 different
> people from 17
> different clouds ran the same workload. And it worked!
> 
> However, one of the reasons it worked is because they
> all used the
> Ansible modules we wrote that are based on the shade
> library that
> contains the business logic needed to hide vendor
> differences in clouds.
> That means that there IS a fantastic OpenStack
> interoperability story -
> but only if you program in Python. That's less awesome.
> 
> 
> So I don't want to criticise this effort, because I'm sure
> that it's
> very valuable and worthy 
> 
> But it does make me sad that we've so thoroughly given up on
> the concept
> of making the OpenStack APIs themselves interoperable that we're
> building an API for our APIs (Yo dawg!) to work around it.
> 
> 
> One could argue that this is just the natural order of things in
> a world
> where programmers are disciplined and practice separation of
> concerns.
> 
> 
> Sure, but the argument would be more convincing if having a bunch of
> interoperable clouds were not the *entire point* of OpenStack :)
> 
> Nova's API is for nova. Keystone's is for Keystone. Oaktree's would
> simply be for multi-cloud users.
> 
> IMO, it's actually just sad, and I'd like for every project's
> API to be
> evolved for multi-cloud users. But seeing as I've seen so very
> little
> of that actually happening, splitting it out seems like a reasonable
> compromise.
> 
> 
> I think we're in agreement.
> 
> The problem is that to take advantage of the
> interoperability benefits
> you'll be locked in to a single orchestration tool
> (Ansible/shade). If
> you have a particular reason to use another tool (possibly,
> ahem, the
> one that is an official part of OpenStack and already
> available in 2/3
> of 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Jeremy Stanley]

On 2016-11-21 15:12:45 -0500 (-0500), Zane Bitter wrote:
[...]
> (Also, the point of floating IPs with access to only the control plane is
> not so instances can access the control plane; it's so that the control
> plane can access the instances without everyone on the internet - or
> whatever other external network you might connect to - necessarily being
> able to do the same.)
[...]

Probably just my knee jerking over what seems like yet another
gratuitously unnecessary use of NAT here, but why not simply use
packet filtering (and if necessary, additional virtual NICs)?
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Steve Baker]

On Tue, Nov 22, 2016 at 9:36 AM, Zane Bitter  wrote:

> On 18/11/16 16:56, Clint Byrum wrote:
>
>> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>>
>>> So, say that I want to create my servers in Heat so that I can use Heat
>>> software deployments for orchestration. How would I go about e.g. making
>>> sure that the servers are always connected to the networks I expect on a
>>> variety of different clouds? Would Oaktree figure out the networks and
>>> pass them in to the stack when creating it? (I don't believe shade has
>>> Heat support yet, but we should definitely add it & I don't foresee any
>>> great obstacle.) Or would Heat have to add Oaktree resource types?
>>>
>>>
>> If you're wanting to use Heat, you are a) already cutting off a large
>> quantity of interoperable clouds because many do not have Heat,
>>
>
> (Roughly one third, according to the user survey.) We have a mechanism to
> resolve that though (defcore), and I'm confident that that will happen in
> due course. I'm less confident that we have any mechanism for resolving
> these other questions.
>
> Perhaps we could use defcore-required Tempest tests to drive alignment on
> some of those too. But we'd have to decide what we want to align on first.
>
> and b)
>> you already have provider templates to deal with the inconsistencies
>> across clouds.
>>
>
> Indeed, and environment files and conditionals as well.
>
> And Shade has had Heat support in some for or another for a long time:
>>
>> 9922cfbb(Monty Taylor   2015-12-03 18:12:32 -0500 32)import
>> heatclient.client
>>
>
> Oh, great! I knew it had been on the agenda for a while but I didn't know
> if it had actually happened or not, so I had a quick glance at
> http://docs.openstack.org/infra/shade/model.html and there was no mention.
>
>
Shade has decent heat support [1] which is behind the os_stack module
available in Ansible 2.2 [2]

My personal workflow involves a lot of ansible playbooks creating/updating
heat stacks then doing other things, and having the os_stack module has
made this much cleaner.

[1]
http://docs.openstack.org/infra/shade/usage.html#shade.OpenStackCloud.create_stack
etc
[2] https://docs.ansible.com/ansible/os_stack_module.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Zane Bitter]

On 18/11/16 16:56, Clint Byrum wrote:

Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:

So, say that I want to create my servers in Heat so that I can use Heat
software deployments for orchestration. How would I go about e.g. making
sure that the servers are always connected to the networks I expect on a
variety of different clouds? Would Oaktree figure out the networks and
pass them in to the stack when creating it? (I don't believe shade has
Heat support yet, but we should definitely add it & I don't foresee any
great obstacle.) Or would Heat have to add Oaktree resource types?



If you're wanting to use Heat, you are a) already cutting off a large
quantity of interoperable clouds because many do not have Heat,


(Roughly one third, according to the user survey.) We have a mechanism 
to resolve that though (defcore), and I'm confident that that will 
happen in due course. I'm less confident that we have any mechanism for 
resolving these other questions.


Perhaps we could use defcore-required Tempest tests to drive alignment 
on some of those too. But we'd have to decide what we want to align on 
first.



and b)
you already have provider templates to deal with the inconsistencies
across clouds.


Indeed, and environment files and conditionals as well.


And Shade has had Heat support in some for or another for a long time:

9922cfbb(Monty Taylor   2015-12-03 18:12:32 -0500 32)import 
heatclient.client


Oh, great! I knew it had been on the agenda for a while but I didn't 
know if it had actually happened or not, so I had a quick glance at 
http://docs.openstack.org/infra/shade/model.html and there was no mention.



To answer your other question, I don't think that's actually desirable or
realistic for interop expectations. If networking were one-size-fits-all
we wouldn't even need Neutron (we had a one-size-fits-all solution, it was
nova-network). We have Neutron so you can construct what you need inside
the cloud.


I'd prefer that we treat Neutron as a way to construct a consistent set 
of abstractions that users can rely on to construct what they need, 
rather than a way to expose the implementation decisions of the operator 
to the user.


(Ditto for all OpenStack projects, actually.)

- ZB


Shade just normalizes the "how do I get to the instances from
outside the cloud" part, which has several different variants.


It sounds to me like the former approach would require all of the same
work in the template that you'd need to handle it now (using
conditionals), and the only real difference is that instead of providing
your own environment file for each cloud you do a bit of oaktree
integration and that figures it out for you instead.

Adding Oaktree resource types to Heat to paper over isn't really a
solution from my point of view.



Agreed, Heat, to me, sits behind Oaktree and Shade, not in front of it.
Mostly just to avoid needing to grok Keystone and all of its glory.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Kevin Benton]

>I'm not saying that you have to supply any IP addresses to the pool. Just
that only the wilfully contrary should call the internet anything other
than "internet", and that we should ensure this *in code* instead of just
hoping that everyone will coincidentally choose the same thing (spoiler:
they don't) so that both end users *and other OpenStack projects* can rely
on it.

A big chunk of enterprise deployments I see don't have real Internet IPs
available as floating IPs, they are just IP addresses reachable from the
whole company network. They are available everywhere they need for their
use cases so all tooling they use can effectively treat them as "Internet"
addresses (reachable from everywhere in their corporate network), but they
are not the real Internet.

So either you force them to lie and call it "internet" to work with tooling
that expects that, or they can't use any tooling built on this new concept
of "internet". Pick your poison.

On Mon, Nov 21, 2016 at 12:12 PM, Zane Bitter  wrote:

> On 18/11/16 16:47, Clint Byrum wrote:
>
>> Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
>>
>>> On 15/11/16 09:56, Monty Taylor wrote:
>>>
 Hey everybody!

 At this past OpenStack Summit the results of the Interop Challenge were
 shown on stage. It was pretty awesome - 17 different people from 17
 different clouds ran the same workload. And it worked!

 However, one of the reasons it worked is because they all used the
 Ansible modules we wrote that are based on the shade library that
 contains the business logic needed to hide vendor differences in clouds.
 That means that there IS a fantastic OpenStack interoperability story -
 but only if you program in Python. That's less awesome.

>>>
>>> So I don't want to criticise this effort, because I'm sure that it's
>>> very valuable and worthy 
>>>
>>> But it does make me sad that we've so thoroughly given up on the concept
>>> of making the OpenStack APIs themselves interoperable that we're
>>> building an API for our APIs (Yo dawg!) to work around it.
>>>
>>>
>> One could argue that this is just the natural order of things in a world
>> where programmers are disciplined and practice separation of concerns.
>>
>
> Sure, but the argument would be more convincing if having a bunch of
> interoperable clouds were not the *entire point* of OpenStack :)
>
> Nova's API is for nova. Keystone's is for Keystone. Oaktree's would
>> simply be for multi-cloud users.
>>
>> IMO, it's actually just sad, and I'd like for every project's API to be
>> evolved for multi-cloud users. But seeing as I've seen so very little
>> of that actually happening, splitting it out seems like a reasonable
>> compromise.
>>
>
> I think we're in agreement.
>
> The problem is that to take advantage of the interoperability benefits
>>> you'll be locked in to a single orchestration tool (Ansible/shade). If
>>> you have a particular reason to use another tool (possibly, ahem, the
>>> one that is an official part of OpenStack and already available in 2/3
>>> of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
>>> choose between whatever feature you wanted there and interoperability.
>>> That's taking "there IS a fantastic OpenStack interoperability story -
>>> but only if you program in Python" and kicking the can one step down the
>>> road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
>>> underlying APIs then *everyone* benefits.
>>>
>>>
>> I know Monty said this, but I want to say it again: gRPC is just HTTP/2
>> + protobufs. Meaning, it's available to virtually every programming
>> language in wide usage at this time (the limiting factor being protobuf
>> implementatoins):
>>
>> https://github.com/google/protobuf/blob/master/docs/third_party.md
>>
>
> I get that, but what I'm spending a lot of my time on is interactions
> between OpenStack components, and that uses the OpenStack APIs because..
> well because they're the OpenStack APIs.
>
> So maybe in the event of a failure occurring somewhere I want to spin up
> some replacement resources, and then put things back how they were again
> later, using a Mistral workflow. And say that oaktree will magically fix
> some cross-cloud interop differences for me when I first spin up my app.
> Now I'm faced with a bad choice: either I have to replicate the magic in a
> second language, because OpenStack doesn't speak shade/oaktree, or I have
> to give up on the magic and just implement everything myself, or I have to
> give up on the idea of doing anything especially interesting at runtime and
> hope my app just keeps working as deployed, or I have to give up on ever
> deploying my app on more than one cloud.
>
> The only thing that will avoid _all_ of those bad choices, and I realise I
> am preaching to the choir here, is if we fix the APIs such that they don't
> *need* magic to work well across clouds.
>
> I feel like the entire 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Zane Bitter]

On 18/11/16 16:47, Clint Byrum wrote:

Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:

On 15/11/16 09:56, Monty Taylor wrote:

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.


So I don't want to criticise this effort, because I'm sure that it's
very valuable and worthy 

But it does make me sad that we've so thoroughly given up on the concept
of making the OpenStack APIs themselves interoperable that we're
building an API for our APIs (Yo dawg!) to work around it.



One could argue that this is just the natural order of things in a world
where programmers are disciplined and practice separation of concerns.


Sure, but the argument would be more convincing if having a bunch of 
interoperable clouds were not the *entire point* of OpenStack :)



Nova's API is for nova. Keystone's is for Keystone. Oaktree's would
simply be for multi-cloud users.

IMO, it's actually just sad, and I'd like for every project's API to be
evolved for multi-cloud users. But seeing as I've seen so very little
of that actually happening, splitting it out seems like a reasonable
compromise.


I think we're in agreement.


The problem is that to take advantage of the interoperability benefits
you'll be locked in to a single orchestration tool (Ansible/shade). If
you have a particular reason to use another tool (possibly, ahem, the
one that is an official part of OpenStack and already available in 2/3
of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
choose between whatever feature you wanted there and interoperability.
That's taking "there IS a fantastic OpenStack interoperability story -
but only if you program in Python" and kicking the can one step down the
road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
underlying APIs then *everyone* benefits.



I know Monty said this, but I want to say it again: gRPC is just HTTP/2
+ protobufs. Meaning, it's available to virtually every programming
language in wide usage at this time (the limiting factor being protobuf
implementatoins):

https://github.com/google/protobuf/blob/master/docs/third_party.md


I get that, but what I'm spending a lot of my time on is interactions 
between OpenStack components, and that uses the OpenStack APIs because.. 
well because they're the OpenStack APIs.


So maybe in the event of a failure occurring somewhere I want to spin up 
some replacement resources, and then put things back how they were again 
later, using a Mistral workflow. And say that oaktree will magically fix 
some cross-cloud interop differences for me when I first spin up my app. 
Now I'm faced with a bad choice: either I have to replicate the magic in 
a second language, because OpenStack doesn't speak shade/oaktree, or I 
have to give up on the magic and just implement everything myself, or I 
have to give up on the idea of doing anything especially interesting at 
runtime and hope my app just keeps working as deployed, or I have to 
give up on ever deploying my app on more than one cloud.


The only thing that will avoid _all_ of those bad choices, and I realise 
I am preaching to the choir here, is if we fix the APIs such that they 
don't *need* magic to work well across clouds.



I feel like the entire OpenStack project has, out of a desire not to be
opinionated, consistently failed both our users and operators by
encouraging all sorts of unnecessarily incompatible configurations. Not
to pick on any particular project but e.g. can anyone tell me why
Neutron doesn't automatically come, out of the box, with external
networks called "internet" and "openstack" so that users can create
floating IPs that talk to either the internet or just the control plane,
respectively, on any OpenStack cloud with a single Heat template (or
whatever) without having to paste UUIDs anywhere? What sane reason could
there be to even allow, let alone force, all operators to solve these
problems independently?



Side note: As of right now, I'm pretty sure the only place where you
should have to use network UUID's pasted somewhere is Octavia.

Also, many OpenStack clouds are not on the internet, and do not want to
give instances access to the control plane. So your example perhaps
needs more thought.


I'm not saying that you have to supply any IP addresses to the pool. 
Just that only the wilfully contrary should call the internet anything 
other than "internet", and that we should ensure this *in code* instead 
of just hoping that everyone will coincidentally 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

On 11/18/2016 04:56 PM, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
>> On 17/11/16 19:01, Monty Taylor wrote:
>>> On 11/17/2016 05:24 PM, Zane Bitter wrote:
 On 15/11/16 09:56, Monty Taylor wrote:
> Hey everybody!
>
> At this past OpenStack Summit the results of the Interop Challenge were
> shown on stage. It was pretty awesome - 17 different people from 17
> different clouds ran the same workload. And it worked!
>
> However, one of the reasons it worked is because they all used the
> Ansible modules we wrote that are based on the shade library that
> contains the business logic needed to hide vendor differences in clouds.
> That means that there IS a fantastic OpenStack interoperability story -
> but only if you program in Python. That's less awesome.

 So I don't want to criticise this effort, because I'm sure that it's
 very valuable and worthy 

 But it does make me sad that we've so thoroughly given up on the concept
 of making the OpenStack APIs themselves interoperable that we're
 building an API for our APIs (Yo dawg!) to work around it.
>>>
>>> Tell me about it. I share your sadness. In fact, that sadness has been
>>> my main state for several years now.
>>>
 The problem is that to take advantage of the interoperability benefits
 you'll be locked in to a single orchestration tool (Ansible/shade). If
 you have a particular reason to use another tool (possibly, ahem, the
 one that is an official part of OpenStack and already available in 2/3
 of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
 choose between whatever feature you wanted there and interoperability.
 That's taking "there IS a fantastic OpenStack interoperability story -
 but only if you program in Python" and kicking the can one step down the
 road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
 underlying APIs then *everyone* benefits.
>>>
>>> I seem to have communicated something very poorly if that's the take
>>> away you've gotten. Today, if you want cross-cloud interop, you pretty
>>> much need to use shade/ansible. That's not cool - because it's limiting
>>> to people wanting to work in python and people wanting to orchestrate in
>>> ansible. It should absolutely not be necessary to want to use those
>>> tools to get the interop story.
>>>
>>> So one of the main reasons to do this is precisely to provide that story
>>> to everyone - whether they're doing Juju and go, or puppet and ruby, or
>>> just programming in Fog or whatnot.
>>
>> So, say that I want to create my servers in Heat so that I can use Heat 
>> software deployments for orchestration. How would I go about e.g. making 
>> sure that the servers are always connected to the networks I expect on a 
>> variety of different clouds? Would Oaktree figure out the networks and 
>> pass them in to the stack when creating it? (I don't believe shade has 
>> Heat support yet, but we should definitely add it & I don't foresee any 
>> great obstacle.) Or would Heat have to add Oaktree resource types?
>>
> 
> If you're wanting to use Heat, you are a) already cutting off a large
> quantity of interoperable clouds because many do not have Heat, and b)
> you already have provider templates to deal with the inconsistencies
> across clouds.
> 
> And Shade has had Heat support in some for or another for a long time:
> 
> 9922cfbb(Monty Taylor   2015-12-03 18:12:32 -0500 32)import 
> heatclient.client

Yah - we have the heat support. That said - so far shade is not in the
business of modifying your heat templates. (and I think we should likely
stay out of that business)

> To answer your other question, I don't think that's actually desirable or
> realistic for interop expectations. If networking were one-size-fits-all
> we wouldn't even need Neutron (we had a one-size-fits-all solution, it was
> nova-network). We have Neutron so you can construct what you need inside
> the cloud. Shade just normalizes the "how do I get to the instances from
> outside the cloud" part, which has several different variants.
>
>> It sounds to me like the former approach would require all of the same 
>> work in the template that you'd need to handle it now (using 
>> conditionals), and the only real difference is that instead of providing 
>> your own environment file for each cloud you do a bit of oaktree 
>> integration and that figures it out for you instead.
>>
>> Adding Oaktree resource types to Heat to paper over isn't really a 
>> solution from my point of view.
>>
> 
> Agreed, Heat, to me, sits behind Oaktree and Shade, not in front of it.
> Mostly just to avoid needing to grok Keystone and all of its glory.

Well - I think at some point in the future we can/should revisit this,
but I agree that right now it's not a thing that should be on heat's
radar. If oaktree installations became at least as 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Clint Byrum]

Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:
> On 15/11/16 09:56, Monty Taylor wrote:
> > Hey everybody!
> >
> > At this past OpenStack Summit the results of the Interop Challenge were
> > shown on stage. It was pretty awesome - 17 different people from 17
> > different clouds ran the same workload. And it worked!
> >
> > However, one of the reasons it worked is because they all used the
> > Ansible modules we wrote that are based on the shade library that
> > contains the business logic needed to hide vendor differences in clouds.
> > That means that there IS a fantastic OpenStack interoperability story -
> > but only if you program in Python. That's less awesome.
> 
> So I don't want to criticise this effort, because I'm sure that it's 
> very valuable and worthy 
> 
> But it does make me sad that we've so thoroughly given up on the concept 
> of making the OpenStack APIs themselves interoperable that we're 
> building an API for our APIs (Yo dawg!) to work around it.
> 

One could argue that this is just the natural order of things in a world
where programmers are disciplined and practice separation of concerns.

Nova's API is for nova. Keystone's is for Keystone. Oaktree's would
simply be for multi-cloud users.

IMO, it's actually just sad, and I'd like for every project's API to be
evolved for multi-cloud users. But seeing as I've seen so very little
of that actually happening, splitting it out seems like a reasonable
compromise.

> The problem is that to take advantage of the interoperability benefits 
> you'll be locked in to a single orchestration tool (Ansible/shade). If 
> you have a particular reason to use another tool (possibly, ahem, the 
> one that is an official part of OpenStack and already available in 2/3 
> of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to 
> choose between whatever feature you wanted there and interoperability. 
> That's taking "there IS a fantastic OpenStack interoperability story - 
> but only if you program in Python" and kicking the can one step down the 
> road (s/program in Python/orchestrate in Ansible). Whereas if we fix the 
> underlying APIs then *everyone* benefits.
> 

I know Monty said this, but I want to say it again: gRPC is just HTTP/2
+ protobufs. Meaning, it's available to virtually every programming
language in wide usage at this time (the limiting factor being protobuf
implementatoins):

https://github.com/google/protobuf/blob/master/docs/third_party.md

> I feel like the entire OpenStack project has, out of a desire not to be 
> opinionated, consistently failed both our users and operators by 
> encouraging all sorts of unnecessarily incompatible configurations. Not 
> to pick on any particular project but e.g. can anyone tell me why 
> Neutron doesn't automatically come, out of the box, with external 
> networks called "internet" and "openstack" so that users can create 
> floating IPs that talk to either the internet or just the control plane, 
> respectively, on any OpenStack cloud with a single Heat template (or 
> whatever) without having to paste UUIDs anywhere? What sane reason could 
> there be to even allow, let alone force, all operators to solve these 
> problems independently?
> 

Side note: As of right now, I'm pretty sure the only place where you
should have to use network UUID's pasted somewhere is Octavia.

Also, many OpenStack clouds are not on the internet, and do not want to
give instances access to the control plane. So your example perhaps
needs more thought.

> I'm sure the infra team can think of 100 pet annoyances like that. So 
> carry on, but maybe y'all could make a list somewhere of all the 
> interoperability problems that shade has had to work around and we could 
> try to make it a priority as a community to address them?
> 

Shade is the python expression of those annoyances. Oaktree would be
exposing that as a gRPC API.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Clint Byrum]

Excerpts from Zane Bitter's message of 2016-11-18 14:24:43 -0500:
> On 17/11/16 19:01, Monty Taylor wrote:
> > On 11/17/2016 05:24 PM, Zane Bitter wrote:
> >> On 15/11/16 09:56, Monty Taylor wrote:
> >>> Hey everybody!
> >>>
> >>> At this past OpenStack Summit the results of the Interop Challenge were
> >>> shown on stage. It was pretty awesome - 17 different people from 17
> >>> different clouds ran the same workload. And it worked!
> >>>
> >>> However, one of the reasons it worked is because they all used the
> >>> Ansible modules we wrote that are based on the shade library that
> >>> contains the business logic needed to hide vendor differences in clouds.
> >>> That means that there IS a fantastic OpenStack interoperability story -
> >>> but only if you program in Python. That's less awesome.
> >>
> >> So I don't want to criticise this effort, because I'm sure that it's
> >> very valuable and worthy 
> >>
> >> But it does make me sad that we've so thoroughly given up on the concept
> >> of making the OpenStack APIs themselves interoperable that we're
> >> building an API for our APIs (Yo dawg!) to work around it.
> >
> > Tell me about it. I share your sadness. In fact, that sadness has been
> > my main state for several years now.
> >
> >> The problem is that to take advantage of the interoperability benefits
> >> you'll be locked in to a single orchestration tool (Ansible/shade). If
> >> you have a particular reason to use another tool (possibly, ahem, the
> >> one that is an official part of OpenStack and already available in 2/3
> >> of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
> >> choose between whatever feature you wanted there and interoperability.
> >> That's taking "there IS a fantastic OpenStack interoperability story -
> >> but only if you program in Python" and kicking the can one step down the
> >> road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
> >> underlying APIs then *everyone* benefits.
> >
> > I seem to have communicated something very poorly if that's the take
> > away you've gotten. Today, if you want cross-cloud interop, you pretty
> > much need to use shade/ansible. That's not cool - because it's limiting
> > to people wanting to work in python and people wanting to orchestrate in
> > ansible. It should absolutely not be necessary to want to use those
> > tools to get the interop story.
> >
> > So one of the main reasons to do this is precisely to provide that story
> > to everyone - whether they're doing Juju and go, or puppet and ruby, or
> > just programming in Fog or whatnot.
> 
> So, say that I want to create my servers in Heat so that I can use Heat 
> software deployments for orchestration. How would I go about e.g. making 
> sure that the servers are always connected to the networks I expect on a 
> variety of different clouds? Would Oaktree figure out the networks and 
> pass them in to the stack when creating it? (I don't believe shade has 
> Heat support yet, but we should definitely add it & I don't foresee any 
> great obstacle.) Or would Heat have to add Oaktree resource types?
>

If you're wanting to use Heat, you are a) already cutting off a large
quantity of interoperable clouds because many do not have Heat, and b)
you already have provider templates to deal with the inconsistencies
across clouds.

And Shade has had Heat support in some for or another for a long time:

9922cfbb(Monty Taylor   2015-12-03 18:12:32 -0500 32)import 
heatclient.client

To answer your other question, I don't think that's actually desirable or
realistic for interop expectations. If networking were one-size-fits-all
we wouldn't even need Neutron (we had a one-size-fits-all solution, it was
nova-network). We have Neutron so you can construct what you need inside
the cloud. Shade just normalizes the "how do I get to the instances from
outside the cloud" part, which has several different variants.

> It sounds to me like the former approach would require all of the same 
> work in the template that you'd need to handle it now (using 
> conditionals), and the only real difference is that instead of providing 
> your own environment file for each cloud you do a bit of oaktree 
> integration and that figures it out for you instead.
> 
> Adding Oaktree resource types to Heat to paper over isn't really a 
> solution from my point of view.
> 

Agreed, Heat, to me, sits behind Oaktree and Shade, not in front of it.
Mostly just to avoid needing to grok Keystone and all of its glory.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Zane Bitter]

On 17/11/16 19:01, Monty Taylor wrote:

On 11/17/2016 05:24 PM, Zane Bitter wrote:

On 15/11/16 09:56, Monty Taylor wrote:

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.


So I don't want to criticise this effort, because I'm sure that it's
very valuable and worthy 

But it does make me sad that we've so thoroughly given up on the concept
of making the OpenStack APIs themselves interoperable that we're
building an API for our APIs (Yo dawg!) to work around it.


Tell me about it. I share your sadness. In fact, that sadness has been
my main state for several years now.


The problem is that to take advantage of the interoperability benefits
you'll be locked in to a single orchestration tool (Ansible/shade). If
you have a particular reason to use another tool (possibly, ahem, the
one that is an official part of OpenStack and already available in 2/3
of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
choose between whatever feature you wanted there and interoperability.
That's taking "there IS a fantastic OpenStack interoperability story -
but only if you program in Python" and kicking the can one step down the
road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
underlying APIs then *everyone* benefits.


I seem to have communicated something very poorly if that's the take
away you've gotten. Today, if you want cross-cloud interop, you pretty
much need to use shade/ansible. That's not cool - because it's limiting
to people wanting to work in python and people wanting to orchestrate in
ansible. It should absolutely not be necessary to want to use those
tools to get the interop story.

So one of the main reasons to do this is precisely to provide that story
to everyone - whether they're doing Juju and go, or puppet and ruby, or
just programming in Fog or whatnot.


So, say that I want to create my servers in Heat so that I can use Heat 
software deployments for orchestration. How would I go about e.g. making 
sure that the servers are always connected to the networks I expect on a 
variety of different clouds? Would Oaktree figure out the networks and 
pass them in to the stack when creating it? (I don't believe shade has 
Heat support yet, but we should definitely add it & I don't foresee any 
great obstacle.) Or would Heat have to add Oaktree resource types?


It sounds to me like the former approach would require all of the same 
work in the template that you'd need to handle it now (using 
conditionals), and the only real difference is that instead of providing 
your own environment file for each cloud you do a bit of oaktree 
integration and that figures it out for you instead.


Adding Oaktree resource types to Heat to paper over isn't really a 
solution from my point of view.



I feel like the entire OpenStack project has, out of a desire not to be
opinionated, consistently failed both our users and operators by
encouraging all sorts of unnecessarily incompatible configurations. Not
to pick on any particular project but e.g. can anyone tell me why
Neutron doesn't automatically come, out of the box, with external
networks called "internet" and "openstack" so that users can create
floating IPs that talk to either the internet or just the control plane,
respectively, on any OpenStack cloud with a single Heat template (or
whatever) without having to paste UUIDs anywhere? What sane reason could
there be to even allow, let alone force, all operators to solve these
problems independently?

I'm sure the infra team can think of 100 pet annoyances like that. So
carry on, but maybe y'all could make a list somewhere of all the
interoperability problems that shade has had to work around and we could
try to make it a priority as a community to address them?


Absolutely happy to. Some are in these slides:

http://inaugust.com/talks/real-slim-shade.html

(http://inaugust.com/talks/real-slim-shade.html#/32 is a good slide to
start with)

But I'd be happy to list out a set of issues in a form that doesn't
involve watching me give a talk.




With that in mind - I'm pleased to announce a new project that aims to
address that - oaktree.

oaktree is a gRPC-based API porcelain service for OpenStack that is
based on the shade library and I'd love some help in writing it.

Basing oaktree on shade gets not only the business logic. Shade already
understands a multi-cloud world. And because we use shade in Infra for
nodepool, it already has caching, batching and thundering herd
protection sorted to 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

On 11/17/2016 05:24 PM, Zane Bitter wrote:
> On 15/11/16 09:56, Monty Taylor wrote:
>> Hey everybody!
>>
>> At this past OpenStack Summit the results of the Interop Challenge were
>> shown on stage. It was pretty awesome - 17 different people from 17
>> different clouds ran the same workload. And it worked!
>>
>> However, one of the reasons it worked is because they all used the
>> Ansible modules we wrote that are based on the shade library that
>> contains the business logic needed to hide vendor differences in clouds.
>> That means that there IS a fantastic OpenStack interoperability story -
>> but only if you program in Python. That's less awesome.
> 
> So I don't want to criticise this effort, because I'm sure that it's
> very valuable and worthy 
> 
> But it does make me sad that we've so thoroughly given up on the concept
> of making the OpenStack APIs themselves interoperable that we're
> building an API for our APIs (Yo dawg!) to work around it.

Tell me about it. I share your sadness. In fact, that sadness has been
my main state for several years now.

> The problem is that to take advantage of the interoperability benefits
> you'll be locked in to a single orchestration tool (Ansible/shade). If
> you have a particular reason to use another tool (possibly, ahem, the
> one that is an official part of OpenStack and already available in 2/3
> of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to
> choose between whatever feature you wanted there and interoperability.
> That's taking "there IS a fantastic OpenStack interoperability story -
> but only if you program in Python" and kicking the can one step down the
> road (s/program in Python/orchestrate in Ansible). Whereas if we fix the
> underlying APIs then *everyone* benefits.

I seem to have communicated something very poorly if that's the take
away you've gotten. Today, if you want cross-cloud interop, you pretty
much need to use shade/ansible. That's not cool - because it's limiting
to people wanting to work in python and people wanting to orchestrate in
ansible. It should absolutely not be necessary to want to use those
tools to get the interop story.

So one of the main reasons to do this is precisely to provide that story
to everyone - whether they're doing Juju and go, or puppet and ruby, or
just programming in Fog or whatnot.

> I feel like the entire OpenStack project has, out of a desire not to be
> opinionated, consistently failed both our users and operators by
> encouraging all sorts of unnecessarily incompatible configurations. Not
> to pick on any particular project but e.g. can anyone tell me why
> Neutron doesn't automatically come, out of the box, with external
> networks called "internet" and "openstack" so that users can create
> floating IPs that talk to either the internet or just the control plane,
> respectively, on any OpenStack cloud with a single Heat template (or
> whatever) without having to paste UUIDs anywhere? What sane reason could
> there be to even allow, let alone force, all operators to solve these
> problems independently?
>
> I'm sure the infra team can think of 100 pet annoyances like that. So
> carry on, but maybe y'all could make a list somewhere of all the
> interoperability problems that shade has had to work around and we could
> try to make it a priority as a community to address them?

Absolutely happy to. Some are in these slides:

http://inaugust.com/talks/real-slim-shade.html

(http://inaugust.com/talks/real-slim-shade.html#/32 is a good slide to
start with)

But I'd be happy to list out a set of issues in a form that doesn't
involve watching me give a talk.

> 
>> With that in mind - I'm pleased to announce a new project that aims to
>> address that - oaktree.
>>
>> oaktree is a gRPC-based API porcelain service for OpenStack that is
>> based on the shade library and I'd love some help in writing it.
>>
>> Basing oaktree on shade gets not only the business logic. Shade already
>> understands a multi-cloud world. And because we use shade in Infra for
>> nodepool, it already has caching, batching and thundering herd
>> protection sorted to be able to hand very high loads efficiently. So
>> while oaktree is new, the primary logic and fundamentals are all shade
>> and are battle-tested.
>>
>> The barrier to deployers adding it to their clouds needs to be as low as
>> humanly possible. So as we work on it, ensuring that we keep it
>> dead-simple to install, update and operate must be a primary concern.
>>
>> Where are we and what's next?
>>
>> oaktree doesn't do a whole lot that's terribly interesting at the
>> moment. We have all of the development scaffolding and gate jobs set up
>> and a few functions implemented.
>>
>> oaktree exists currently as two repos - oaktree and oaktreemodel:
>>
>>   http://git.openstack.org/cgit/openstack/oaktree
>>   http://git.openstack.org/cgit/openstack/oaktreemodel
>>
>> oaktreemodel contains the Protobuf definitions and the build scripts to
>> produce 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Zane Bitter]

On 15/11/16 09:56, Monty Taylor wrote:

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.


So I don't want to criticise this effort, because I'm sure that it's 
very valuable and worthy 


But it does make me sad that we've so thoroughly given up on the concept 
of making the OpenStack APIs themselves interoperable that we're 
building an API for our APIs (Yo dawg!) to work around it.


The problem is that to take advantage of the interoperability benefits 
you'll be locked in to a single orchestration tool (Ansible/shade). If 
you have a particular reason to use another tool (possibly, ahem, the 
one that is an official part of OpenStack and already available in 2/3 
of OpenStack clouds... but also Puppet, JuJu, ) then you'll have to 
choose between whatever feature you wanted there and interoperability. 
That's taking "there IS a fantastic OpenStack interoperability story - 
but only if you program in Python" and kicking the can one step down the 
road (s/program in Python/orchestrate in Ansible). Whereas if we fix the 
underlying APIs then *everyone* benefits.


I feel like the entire OpenStack project has, out of a desire not to be 
opinionated, consistently failed both our users and operators by 
encouraging all sorts of unnecessarily incompatible configurations. Not 
to pick on any particular project but e.g. can anyone tell me why 
Neutron doesn't automatically come, out of the box, with external 
networks called "internet" and "openstack" so that users can create 
floating IPs that talk to either the internet or just the control plane, 
respectively, on any OpenStack cloud with a single Heat template (or 
whatever) without having to paste UUIDs anywhere? What sane reason could 
there be to even allow, let alone force, all operators to solve these 
problems independently?


I'm sure the infra team can think of 100 pet annoyances like that. So 
carry on, but maybe y'all could make a list somewhere of all the 
interoperability problems that shade has had to work around and we could 
try to make it a priority as a community to address them?


cheers,
Zane.


With that in mind - I'm pleased to announce a new project that aims to
address that - oaktree.

oaktree is a gRPC-based API porcelain service for OpenStack that is
based on the shade library and I'd love some help in writing it.

Basing oaktree on shade gets not only the business logic. Shade already
understands a multi-cloud world. And because we use shade in Infra for
nodepool, it already has caching, batching and thundering herd
protection sorted to be able to hand very high loads efficiently. So
while oaktree is new, the primary logic and fundamentals are all shade
and are battle-tested.

The barrier to deployers adding it to their clouds needs to be as low as
humanly possible. So as we work on it, ensuring that we keep it
dead-simple to install, update and operate must be a primary concern.

Where are we and what's next?

oaktree doesn't do a whole lot that's terribly interesting at the
moment. We have all of the development scaffolding and gate jobs set up
and a few functions implemented.

oaktree exists currently as two repos - oaktree and oaktreemodel:

  http://git.openstack.org/cgit/openstack/oaktree
  http://git.openstack.org/cgit/openstack/oaktreemodel

oaktreemodel contains the Protobuf definitions and the build scripts to
produce Python, C++ and Go code from them. The python code is published
to PyPI as a normal pure-python library. The C++ code is published as a
source tarball and the Go code is checked back in to the same repo so
that go works properly.

oaktree depends on the python oaktreemodel library, and also on shade.
It implements the server portion of the gRPC service definition.

Currently, oaktree can list and search for flavors, images and floating
ips. Exciting right? Most of the work to expose the rest of the API that
shade can provide at the moment is going to be fairly straightforward -
although in each case figuring out the best mapping will take some care.

We have a few major things that need some good community design. These
are also listed in a todo.rst file in the oaktree repo which is part of
the docs:

  http://oaktree.readthedocs.io/en/latest/

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

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[joehuang]

>From encapsulation perspective, it's quite good for multi-steps approach to 
>make it being consistently with different version of image upload.

Another thought about Oaktree as a service: would it be a job for Oaktree to 
find proper OpenStack? 

For the location could be varied in different time for the same API calling, 
the end user may specify region or not, may specify az or not. So if
an end user does not specify region in instance creation, should Oaktree 
schedule one?

If Oaktree only intends to support different language library through gRPC, 
then would the encapsulation around Shade locally will be enough?

Best Regards
Chaoyi Huang (joehuang)


From: Monty Taylor [mord...@inaugust.com]
Sent: 16 November 2016 23:58
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - 
anybody want to help?

On 11/16/2016 09:34 AM, Monty Taylor wrote:
> On 11/15/2016 11:26 PM, joehuang wrote:
>>> 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.
>>
>> From bandwidth consideration, the bandwidth for the API service like Oaktree
>> may not as wide as that for data storage service, for example Swift. That 
>> means
>> if the Oaktree will proxy the image upload, then the bandwidth for the 
>> Oaktree
>> sever may be exhausted soon, and not  able to provide other API service.
>
> Yes - this is exactly right and a big part of the problem.
>
>> It's good in Glance V2 that image could be update to a store, then register 
>> the location
>> to a Glance image, but not directly upload bits to Glance API directly.
>
> Unfortunately for us - we need to support glance v1 PUT, glance v2 PUT,
> glance v2 task import and the new and upcoming glance v2 multi-step
> image upload.
>
> I had an idea this morning though - tell me what you think.
>
> The API will be multi-step (similar to the new glance image upload
> process) but with explicit instructions for users. We'll suggest that
> client lib authors who are building friendly libs on top of the oaktree
> client encapsulate the multi-step logic in some manner, and we will
> provide explicit instructions on what the multi-steps are.
>
> API:
>
> rpc CreateImage (ImageSpec) returns (ImageUpload) {}
> rpc UploadImageContent (stream ImageContent) returns (ImageUploadStatus) {}
> rpc FinalizeImageUpload (ImageSpec) returns (Image) {}
>
> rpc GetToken (Location) returns (Token) {}
>
> message ImageSpec {
>   Location location = 1;
>   string name = 3;
>   uint32 min_ram = 4;
>   uint64 min_disk = 5;
>   // etc - more fields
>   repeated bytes image_content = 99;
> };
>
> message ImageUpload {
>   enum UploadScheme {
> grpc_upload = 0;
> rest_put = 1;
> swift = 2;
>   };
>   UploadScheme scheme = 1;
>   string endpoint = 2;

Ooh! What if endpoint was actually a repeated field (array)? That way
for PUT operations it would just be a single entry - but for the swift
case, the SLO segment URLs could be pre-computed by oaktree.

It would make "size" a hard requirement from the API - but I'm fine with
that.

Logic below ...

>   map<string, string> headers = 3;
>   uint32 segement_size = 4;
> };
>
> The logic is then:
>
> image_spec = ImageSpec(
> name='my_image')
> upload = client.CreateImage(image_spec)
> if upload.scheme == ImageUpload.grpc_upload:
> image = client.UploadImage(open('file', 'r'))
> elif upload.scheme == ImageUpload.rest_put:
> image = requests.put(
> upload.endpoint, headers=upload.headers,
> data=open('file', 'r'))
> elif upload.scheme = ImageUpload.swift:
> # upload to upload.endpoint, probably as a
> # swift SLO splitting the content into
> # segments of upload.segment_size
 count = 0
 content = open('file', 'r')
 for endpoint in upload.endpoints:
 content.seek(count * upload.segment_size)
 requests.put(
 endpoint, headers=upload.headers,
 data=content.read(upload.segment_size))
 count += 1

Making that multi-threaded is an obvious improvement of course.

> image = client.FinalizeImageUpload(image_spec)

Then the creation of the manifest object in swift could be handled in
fi

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Dean Troyer]

On Wed, Nov 16, 2016 at 9:34 AM, Monty Taylor  wrote:
> (there are parts of this that are hand-wavey - but how does it sound in
> general?)

That sounds basically good because that noise I heard last night must
have been you sneaking in and stealing those steps from my white board
for what OSC will do with Glance.

OSC will have a one-step upload at the CLI, even if we also have to
expose some of the multi-steps separately in order to allow more
complex flows to happen.  The thing I like best is I can draw a line
through my 'poll for status' step when using gRPC!

dt

-- 

Dean Troyer
dtro...@gmail.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Brad Topol]

No Morgan.  You were supposed to stay quiet on this so we could spread vial
behind the scenes rumors on how Monty is trying to bring back CORBA!!! My
apologies to all the young folks not familiar with CORBA...

On a serious note this work has the potential to be extremely valuable and
I am look forward to seeing how it matures.  Is there an easy way for busy
folks to stay up to date on how this progresses? Ideally the interop
challenge work (which is continuing forward) should hopefully be able to
take advantage of the innovations that this project will deliver.


Thanks,

Brad

Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Morgan Fainberg <morgan.fainb...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   11/15/2016 08:42 PM
Subject:        Re: [openstack-dev] oaktree - a friendly end-user oriented API
    layer - anybody want to help?





On Tue, Nov 15, 2016 at 5:16 PM, Jay Pipes <jaypi...@gmail.com> wrote:
  Awesome start, Monty :) Comments inline.

  On 11/15/2016 09:56 AM, Monty Taylor wrote:
   Hey everybody!

   At this past OpenStack Summit the results of the Interop Challenge were
   shown on stage. It was pretty awesome - 17 different people from 17
   different clouds ran the same workload. And it worked!

   However, one of the reasons it worked is because they all used the
   Ansible modules we wrote that are based on the shade library that
   contains the business logic needed to hide vendor differences in clouds.
   That means that there IS a fantastic OpenStack interoperability story -
   but only if you program in Python. That's less awesome.

   With that in mind - I'm pleased to announce a new project that aims to
   address that - oaktree.

   oaktree is a gRPC-based API porcelain service for OpenStack that is
   based on the shade library and I'd love some help in writing it.

   Basing oaktree on shade gets not only the business logic. Shade already
   understands a multi-cloud world. And because we use shade in Infra for
   nodepool, it already has caching, batching and thundering herd
   protection sorted to be able to hand very high loads efficiently. So
   while oaktree is new, the primary logic and fundamentals are all shade
   and are battle-tested.

  ++ muy bueno.

   The barrier to deployers adding it to their clouds needs to be as low as
   humanly possible. So as we work on it, ensuring that we keep it
   dead-simple to install, update and operate must be a primary concern.

   Where are we and what's next?

   oaktree doesn't do a whole lot that's terribly interesting at the
   moment. We have all of the development scaffolding and gate jobs set up
   and a few functions implemented.

   oaktree exists currently as two repos - oaktree and oaktreemodel:

     http://git.openstack.org/cgit/openstack/oaktree
     http://git.openstack.org/cgit/openstack/oaktreemodel

   oaktreemodel contains the Protobuf definitions and the build scripts to
   produce Python, C++ and Go code from them. The python code is published
   to PyPI as a normal pure-python library. The C++ code is published as a
   source tarball and the Go code is checked back in to the same repo so
   that go works properly.

  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!).

  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.

   oaktree depends on the python oaktreemodel library, and also on shade.
   It implements the server portion of the gRPC service definition.

   Currently, oaktree can list and search for flavors, images and floating
   ips. Exciting right? Most of the work to expose the rest of the API that
   shade can provide at the moment is going to be fairly straightforward -
   although in each case figuring out the best mapping will take some care.

   We have a few major things that need some good community design. These
   are also listed in a todo.rst file in the oaktree repo which is part of
   the docs:

     http://oaktree.readthedocs.io/en/latest/

   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 man

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

On 11/16/2016 09:34 AM, Monty Taylor wrote:
> On 11/15/2016 11:26 PM, joehuang wrote:
>>> 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.
>>
>> From bandwidth consideration, the bandwidth for the API service like Oaktree 
>> may not as wide as that for data storage service, for example Swift. That 
>> means
>> if the Oaktree will proxy the image upload, then the bandwidth for the 
>> Oaktree
>> sever may be exhausted soon, and not  able to provide other API service.
> 
> Yes - this is exactly right and a big part of the problem.
> 
>> It's good in Glance V2 that image could be update to a store, then register 
>> the location
>> to a Glance image, but not directly upload bits to Glance API directly.
> 
> Unfortunately for us - we need to support glance v1 PUT, glance v2 PUT,
> glance v2 task import and the new and upcoming glance v2 multi-step
> image upload.
> 
> I had an idea this morning though - tell me what you think.
> 
> The API will be multi-step (similar to the new glance image upload
> process) but with explicit instructions for users. We'll suggest that
> client lib authors who are building friendly libs on top of the oaktree
> client encapsulate the multi-step logic in some manner, and we will
> provide explicit instructions on what the multi-steps are.
> 
> API:
> 
> rpc CreateImage (ImageSpec) returns (ImageUpload) {}
> rpc UploadImageContent (stream ImageContent) returns (ImageUploadStatus) {}
> rpc FinalizeImageUpload (ImageSpec) returns (Image) {}
> 
> rpc GetToken (Location) returns (Token) {}
> 
> message ImageSpec {
>   Location location = 1;
>   string name = 3;
>   uint32 min_ram = 4;
>   uint64 min_disk = 5;
>   // etc - more fields
>   repeated bytes image_content = 99;
> };
> 
> message ImageUpload {
>   enum UploadScheme {
> grpc_upload = 0;
> rest_put = 1;
> swift = 2;
>   };
>   UploadScheme scheme = 1;
>   string endpoint = 2;

Ooh! What if endpoint was actually a repeated field (array)? That way
for PUT operations it would just be a single entry - but for the swift
case, the SLO segment URLs could be pre-computed by oaktree.

It would make "size" a hard requirement from the API - but I'm fine with
that.

Logic below ...

>   map headers = 3;
>   uint32 segement_size = 4;
> };
> 
> The logic is then:
> 
> image_spec = ImageSpec(
> name='my_image')
> upload = client.CreateImage(image_spec)
> if upload.scheme == ImageUpload.grpc_upload:
> image = client.UploadImage(open('file', 'r'))
> elif upload.scheme == ImageUpload.rest_put:
> image = requests.put(
> upload.endpoint, headers=upload.headers,
> data=open('file', 'r'))
> elif upload.scheme = ImageUpload.swift:
> # upload to upload.endpoint, probably as a
> # swift SLO splitting the content into
> # segments of upload.segment_size
 count = 0
 content = open('file', 'r')
 for endpoint in upload.endpoints:
 content.seek(count * upload.segment_size)
 requests.put(
 endpoint, headers=upload.headers,
 data=content.read(upload.segment_size))
 count += 1

Making that multi-threaded is an obvious improvement of course.

> image = client.FinalizeImageUpload(image_spec)

Then the creation of the manifest object in swift could be handled in
finalize by oaktree. In fact- that way we could collapse the put and
swift cases to just be a "REST" case - since all of the operations are
PUT to a URL provided by oaktree - and for glance PUT segment_size will
just be == size.

> It's a three-pronged upload approach that a client author has to write -
> but the two different REST interactions should be easy - the grpc
> endpoint should be able to return endpoint/headers/token so that the end
> user doens't have to interpret _What_ rest call to make - just needs to
> make the exact one that ImageUpload message describes. (the swift upload
> can be documented more precisely - but this email is already long)
> 
> For the swift case, it's possible that the token could expire before all
> of the PUTs are made for each of the image segments. That's why we add a
> GetToken api call - so that in a loop the client can just request
> another token from the gRPC api without having to know anything more
> about those mechanics. Obviously that can also be hidden by client libs
> too - but in a way that's easily replicatable across langauges - and if
> someone wants to do things by hand, there are very explicit instructions.
> 
> The finalize step is important because there are things that may 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

On 11/15/2016 07:16 PM, Jay Pipes wrote:
> Awesome start, Monty :) Comments inline.

Yay - thanks Jay!

> On 11/15/2016 09:56 AM, Monty Taylor wrote:
>> Hey everybody!
>>
>> At this past OpenStack Summit the results of the Interop Challenge were
>> shown on stage. It was pretty awesome - 17 different people from 17
>> different clouds ran the same workload. And it worked!
>>
>> However, one of the reasons it worked is because they all used the
>> Ansible modules we wrote that are based on the shade library that
>> contains the business logic needed to hide vendor differences in clouds.
>> That means that there IS a fantastic OpenStack interoperability story -
>> but only if you program in Python. That's less awesome.
>>
>> With that in mind - I'm pleased to announce a new project that aims to
>> address that - oaktree.
>>
>> oaktree is a gRPC-based API porcelain service for OpenStack that is
>> based on the shade library and I'd love some help in writing it.
>>
>> Basing oaktree on shade gets not only the business logic. Shade already
>> understands a multi-cloud world. And because we use shade in Infra for
>> nodepool, it already has caching, batching and thundering herd
>> protection sorted to be able to hand very high loads efficiently. So
>> while oaktree is new, the primary logic and fundamentals are all shade
>> and are battle-tested.
> 
> ++ muy bueno.
> 
>> The barrier to deployers adding it to their clouds needs to be as low as
>> humanly possible. So as we work on it, ensuring that we keep it
>> dead-simple to install, update and operate must be a primary concern.
>>
>> Where are we and what's next?
>>
>> oaktree doesn't do a whole lot that's terribly interesting at the
>> moment. We have all of the development scaffolding and gate jobs set up
>> and a few functions implemented.
>>
>> oaktree exists currently as two repos - oaktree and oaktreemodel:
>>
>>   http://git.openstack.org/cgit/openstack/oaktree
>>   http://git.openstack.org/cgit/openstack/oaktreemodel
>>
>> oaktreemodel contains the Protobuf definitions and the build scripts to
>> produce Python, C++ and Go code from them. The python code is published
>> to PyPI as a normal pure-python library. The C++ code is published as a
>> source tarball and the Go code is checked back in to the same repo so
>> that go works properly.
> 
> 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!).

Well, I've got the protoc -> golang generation working in the gate, so
one step down.

> 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.

Yah - turns out they're pretty awesome. They are less flexible in many
respects to REST - but so far I'm finding the limitations are actually
quite nice.

Also - you'll note that oaktreemodel has inherited code from Drizzle's
build system. :)

>> oaktree depends on the python oaktreemodel library, and also on shade.
>> It implements the server portion of the gRPC service definition.
>>
>> Currently, oaktree can list and search for flavors, images and floating
>> ips. Exciting right? Most of the work to expose the rest of the API that
>> shade can provide at the moment is going to be fairly straightforward -
>> although in each case figuring out the best mapping will take some care.
>>
>> We have a few major things that need some good community design. These
>> are also listed in a todo.rst file in the oaktree repo which is part of
>> the docs:
>>
>>   http://oaktree.readthedocs.io/en/latest/
>>
>> 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.
>>
>> Glance Image Uploads and Swift Object Uploads (and downloads). Having
>> those two data operations go through an API proxy seems inefficient.
> 
> Uh, yeah :)
> 
>> 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 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

On 11/15/2016 11:26 PM, joehuang wrote:
>> 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.
> 
> From bandwidth consideration, the bandwidth for the API service like Oaktree 
> may not as wide as that for data storage service, for example Swift. That 
> means
> if the Oaktree will proxy the image upload, then the bandwidth for the Oaktree
> sever may be exhausted soon, and not  able to provide other API service.

Yes - this is exactly right and a big part of the problem.

> It's good in Glance V2 that image could be update to a store, then register 
> the location
> to a Glance image, but not directly upload bits to Glance API directly.

Unfortunately for us - we need to support glance v1 PUT, glance v2 PUT,
glance v2 task import and the new and upcoming glance v2 multi-step
image upload.

I had an idea this morning though - tell me what you think.

The API will be multi-step (similar to the new glance image upload
process) but with explicit instructions for users. We'll suggest that
client lib authors who are building friendly libs on top of the oaktree
client encapsulate the multi-step logic in some manner, and we will
provide explicit instructions on what the multi-steps are.

API:

rpc CreateImage (ImageSpec) returns (ImageUpload) {}
rpc UploadImageContent (stream ImageContent) returns (ImageUploadStatus) {}
rpc FinalizeImageUpload (ImageSpec) returns (Image) {}

rpc GetToken (Location) returns (Token) {}

message ImageSpec {
  Location location = 1;
  string name = 3;
  uint32 min_ram = 4;
  uint64 min_disk = 5;
  // etc - more fields
  repeated bytes image_content = 99;
};

message ImageUpload {
  enum UploadScheme {
grpc_upload = 0;
rest_put = 1;
swift = 2;
  };
  UploadScheme scheme = 1;
  string endpoint = 2;
  map headers = 3;
  uint32 segement_size = 4;
};

The logic is then:

image_spec = ImageSpec(
name='my_image')
upload = client.CreateImage(image_spec)
if upload.scheme == ImageUpload.grpc_upload:
image = client.UploadImage(open('file', 'r'))
elif upload.scheme == ImageUpload.rest_put:
image = requests.put(
upload.endpoint, headers=upload.headers,
data=open('file', 'r'))
elif upload.scheme = ImageUpload.swift:
# upload to upload.endpoint, probably as a
# swift SLO splitting the content into
# segments of upload.segment_size
image = client.FinalizeImageUpload(image_spec)

It's a three-pronged upload approach that a client author has to write -
but the two different REST interactions should be easy - the grpc
endpoint should be able to return endpoint/headers/token so that the end
user doens't have to interpret _What_ rest call to make - just needs to
make the exact one that ImageUpload message describes. (the swift upload
can be documented more precisely - but this email is already long)

For the swift case, it's possible that the token could expire before all
of the PUTs are made for each of the image segments. That's why we add a
GetToken api call - so that in a loop the client can just request
another token from the gRPC api without having to know anything more
about those mechanics. Obviously that can also be hidden by client libs
too - but in a way that's easily replicatable across langauges - and if
someone wants to do things by hand, there are very explicit instructions.

The finalize step is important because there are things that may need to
be performed after the upload in all cases. For the swift case, the
import task has to be spawned and waited on. For the put and gRPC cases
there are metadata fields, like protected, that can only be set once the
other actions are complete.

(there are parts of this that are hand-wavey - but how does it sound in
general?)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[joehuang]

Consider that Shade/Oaktree will interact with multiple clouds, it's necessary 
to establish check and gate test
environment for multi-clouds. This is also one requirement from Tricircle.

Best Regards
Chaoyi Huang (joehuang)

From: Monty Taylor [mord...@inaugust.com]
Sent: 15 November 2016 22:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] oaktree - a friendly end-user oriented API layer - 
anybody want to help?

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.

With that in mind - I'm pleased to announce a new project that aims to
address that - oaktree.

oaktree is a gRPC-based API porcelain service for OpenStack that is
based on the shade library and I'd love some help in writing it.

Basing oaktree on shade gets not only the business logic. Shade already
understands a multi-cloud world. And because we use shade in Infra for
nodepool, it already has caching, batching and thundering herd
protection sorted to be able to hand very high loads efficiently. So
while oaktree is new, the primary logic and fundamentals are all shade
and are battle-tested.

The barrier to deployers adding it to their clouds needs to be as low as
humanly possible. So as we work on it, ensuring that we keep it
dead-simple to install, update and operate must be a primary concern.

Where are we and what's next?

oaktree doesn't do a whole lot that's terribly interesting at the
moment. We have all of the development scaffolding and gate jobs set up
and a few functions implemented.

oaktree exists currently as two repos - oaktree and oaktreemodel:

  http://git.openstack.org/cgit/openstack/oaktree
  http://git.openstack.org/cgit/openstack/oaktreemodel

oaktreemodel contains the Protobuf definitions and the build scripts to
produce Python, C++ and Go code from them. The python code is published
to PyPI as a normal pure-python library. The C++ code is published as a
source tarball and the Go code is checked back in to the same repo so
that go works properly.

oaktree depends on the python oaktreemodel library, and also on shade.
It implements the server portion of the gRPC service definition.

Currently, oaktree can list and search for flavors, images and floating
ips. Exciting right? Most of the work to expose the rest of the API that
shade can provide at the moment is going to be fairly straightforward -
although in each case figuring out the best mapping will take some care.

We have a few major things that need some good community design. These
are also listed in a todo.rst file in the oaktree repo which is part of
the docs:

  http://oaktree.readthedocs.io/en/latest/

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.

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.

In any case - I'd love help from anyone who thinks this sounds like a
good idea. In a perfect world we'll have something ready for 1.0 by Atlanta.

Join us in #openstack-shade if you want to hack.

Thanks!
Monty


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[joehuang]

> 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.

>From bandwidth consideration, the bandwidth for the API service like Oaktree 
may not as wide as that for data storage service, for example Swift. That means
if the Oaktree will proxy the image upload, then the bandwidth for the Oaktree
sever may be exhausted soon, and not  able to provide other API service.

It's good in Glance V2 that image could be update to a store, then register the 
location
to a Glance image, but not directly upload bits to Glance API directly.

Best Regards
Chaoyi Huang (joehuang)


From: Monty Taylor [mord...@inaugust.com]
Sent: 15 November 2016 22:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] oaktree - a friendly end-user oriented API layer - 
anybody want to help?

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.

With that in mind - I'm pleased to announce a new project that aims to
address that - oaktree.

oaktree is a gRPC-based API porcelain service for OpenStack that is
based on the shade library and I'd love some help in writing it.

Basing oaktree on shade gets not only the business logic. Shade already
understands a multi-cloud world. And because we use shade in Infra for
nodepool, it already has caching, batching and thundering herd
protection sorted to be able to hand very high loads efficiently. So
while oaktree is new, the primary logic and fundamentals are all shade
and are battle-tested.

The barrier to deployers adding it to their clouds needs to be as low as
humanly possible. So as we work on it, ensuring that we keep it
dead-simple to install, update and operate must be a primary concern.

Where are we and what's next?

oaktree doesn't do a whole lot that's terribly interesting at the
moment. We have all of the development scaffolding and gate jobs set up
and a few functions implemented.

oaktree exists currently as two repos - oaktree and oaktreemodel:

  http://git.openstack.org/cgit/openstack/oaktree
  http://git.openstack.org/cgit/openstack/oaktreemodel

oaktreemodel contains the Protobuf definitions and the build scripts to
produce Python, C++ and Go code from them. The python code is published
to PyPI as a normal pure-python library. The C++ code is published as a
source tarball and the Go code is checked back in to the same repo so
that go works properly.

oaktree depends on the python oaktreemodel library, and also on shade.
It implements the server portion of the gRPC service definition.

Currently, oaktree can list and search for flavors, images and floating
ips. Exciting right? Most of the work to expose the rest of the API that
shade can provide at the moment is going to be fairly straightforward -
although in each case figuring out the best mapping will take some care.

We have a few major things that need some good community design. These
are also listed in a todo.rst file in the oaktree repo which is part of
the docs:

  http://oaktree.readthedocs.io/en/latest/

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.

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 ac

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Morgan Fainberg]

On Tue, Nov 15, 2016 at 5:16 PM, Jay Pipes  wrote:

> Awesome start, Monty :) Comments inline.
>
> On 11/15/2016 09:56 AM, Monty Taylor wrote:
>
>> Hey everybody!
>>
>> At this past OpenStack Summit the results of the Interop Challenge were
>> shown on stage. It was pretty awesome - 17 different people from 17
>> different clouds ran the same workload. And it worked!
>>
>> However, one of the reasons it worked is because they all used the
>> Ansible modules we wrote that are based on the shade library that
>> contains the business logic needed to hide vendor differences in clouds.
>> That means that there IS a fantastic OpenStack interoperability story -
>> but only if you program in Python. That's less awesome.
>>
>> With that in mind - I'm pleased to announce a new project that aims to
>> address that - oaktree.
>>
>> oaktree is a gRPC-based API porcelain service for OpenStack that is
>> based on the shade library and I'd love some help in writing it.
>>
>> Basing oaktree on shade gets not only the business logic. Shade already
>> understands a multi-cloud world. And because we use shade in Infra for
>> nodepool, it already has caching, batching and thundering herd
>> protection sorted to be able to hand very high loads efficiently. So
>> while oaktree is new, the primary logic and fundamentals are all shade
>> and are battle-tested.
>>
>
> ++ muy bueno.
>
> The barrier to deployers adding it to their clouds needs to be as low as
>> humanly possible. So as we work on it, ensuring that we keep it
>> dead-simple to install, update and operate must be a primary concern.
>>
>> Where are we and what's next?
>>
>> oaktree doesn't do a whole lot that's terribly interesting at the
>> moment. We have all of the development scaffolding and gate jobs set up
>> and a few functions implemented.
>>
>> oaktree exists currently as two repos - oaktree and oaktreemodel:
>>
>>   http://git.openstack.org/cgit/openstack/oaktree
>>   http://git.openstack.org/cgit/openstack/oaktreemodel
>>
>> oaktreemodel contains the Protobuf definitions and the build scripts to
>> produce Python, C++ and Go code from them. The python code is published
>> to PyPI as a normal pure-python library. The C++ code is published as a
>> source tarball and the Go code is checked back in to the same repo so
>> that go works properly.
>>
>
> 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!).
>
> 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.
>
> oaktree depends on the python oaktreemodel library, and also on shade.
>> It implements the server portion of the gRPC service definition.
>>
>> Currently, oaktree can list and search for flavors, images and floating
>> ips. Exciting right? Most of the work to expose the rest of the API that
>> shade can provide at the moment is going to be fairly straightforward -
>> although in each case figuring out the best mapping will take some care.
>>
>> We have a few major things that need some good community design. These
>> are also listed in a todo.rst file in the oaktree repo which is part of
>> the docs:
>>
>>   http://oaktree.readthedocs.io/en/latest/
>>
>> 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.
>>
>> Glance Image Uploads and Swift Object Uploads (and downloads). Having
>> those two data operations go through an API proxy seems inefficient.
>>
>
> Uh, yeah :)
>
> 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.
>>
>> In any case - I'd love help from anyone who thinks this sounds like a
>> good idea. In a perfect world we'll have something ready for 1.0 by
>> Atlanta.
>>
>
> I'll try my best to dig into the 

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Jay Pipes]

Awesome start, Monty :) Comments inline.

On 11/15/2016 09:56 AM, Monty Taylor wrote:

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.

With that in mind - I'm pleased to announce a new project that aims to
address that - oaktree.

oaktree is a gRPC-based API porcelain service for OpenStack that is
based on the shade library and I'd love some help in writing it.

Basing oaktree on shade gets not only the business logic. Shade already
understands a multi-cloud world. And because we use shade in Infra for
nodepool, it already has caching, batching and thundering herd
protection sorted to be able to hand very high loads efficiently. So
while oaktree is new, the primary logic and fundamentals are all shade
and are battle-tested.


++ muy bueno.


The barrier to deployers adding it to their clouds needs to be as low as
humanly possible. So as we work on it, ensuring that we keep it
dead-simple to install, update and operate must be a primary concern.

Where are we and what's next?

oaktree doesn't do a whole lot that's terribly interesting at the
moment. We have all of the development scaffolding and gate jobs set up
and a few functions implemented.

oaktree exists currently as two repos - oaktree and oaktreemodel:

  http://git.openstack.org/cgit/openstack/oaktree
  http://git.openstack.org/cgit/openstack/oaktreemodel

oaktreemodel contains the Protobuf definitions and the build scripts to
produce Python, C++ and Go code from them. The python code is published
to PyPI as a normal pure-python library. The C++ code is published as a
source tarball and the Go code is checked back in to the same repo so
that go works properly.


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!).


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.



oaktree depends on the python oaktreemodel library, and also on shade.
It implements the server portion of the gRPC service definition.

Currently, oaktree can list and search for flavors, images and floating
ips. Exciting right? Most of the work to expose the rest of the API that
shade can provide at the moment is going to be fairly straightforward -
although in each case figuring out the best mapping will take some care.

We have a few major things that need some good community design. These
are also listed in a todo.rst file in the oaktree repo which is part of
the docs:

  http://oaktree.readthedocs.io/en/latest/

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.

Glance Image Uploads and Swift Object Uploads (and downloads). Having
those two data operations go through an API proxy seems inefficient.


Uh, yeah :)


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.

In any case - I'd love help from anyone who thinks this sounds like a
good idea. In a perfect world we'll have something ready for 1.0 by Atlanta.


I'll try my best to dig into the code this week/end.

Best,
-jay


Join us in #openstack-shade if you want to hack.

Thanks!
Monty


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Dean Troyer]

On Tue, Nov 15, 2016 at 8:56 AM, Monty Taylor  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
dtro...@gmail.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Sean M. Collins]

Great idea, I just ran into a similar issue when investigating the
following Kubernetes issue[1], and the OpenStack provider. They are running
into similar issues around networking and what a "public" network
address is, which is exactly what Shade had to deal with, in the public
clouds that we use for our testing infrastructure.

https://github.com/kubernetes/kubernetes/issues/12083

Obviously since k8s is written in Go, they can't really use Shade out of
the box - so this new project you are working on is *exactly* what the
doctor ordered.

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?

[Monty Taylor]

Hey everybody!

At this past OpenStack Summit the results of the Interop Challenge were
shown on stage. It was pretty awesome - 17 different people from 17
different clouds ran the same workload. And it worked!

However, one of the reasons it worked is because they all used the
Ansible modules we wrote that are based on the shade library that
contains the business logic needed to hide vendor differences in clouds.
That means that there IS a fantastic OpenStack interoperability story -
but only if you program in Python. That's less awesome.

With that in mind - I'm pleased to announce a new project that aims to
address that - oaktree.

oaktree is a gRPC-based API porcelain service for OpenStack that is
based on the shade library and I'd love some help in writing it.

Basing oaktree on shade gets not only the business logic. Shade already
understands a multi-cloud world. And because we use shade in Infra for
nodepool, it already has caching, batching and thundering herd
protection sorted to be able to hand very high loads efficiently. So
while oaktree is new, the primary logic and fundamentals are all shade
and are battle-tested.

The barrier to deployers adding it to their clouds needs to be as low as
humanly possible. So as we work on it, ensuring that we keep it
dead-simple to install, update and operate must be a primary concern.

Where are we and what's next?

oaktree doesn't do a whole lot that's terribly interesting at the
moment. We have all of the development scaffolding and gate jobs set up
and a few functions implemented.

oaktree exists currently as two repos - oaktree and oaktreemodel:

  http://git.openstack.org/cgit/openstack/oaktree
  http://git.openstack.org/cgit/openstack/oaktreemodel

oaktreemodel contains the Protobuf definitions and the build scripts to
produce Python, C++ and Go code from them. The python code is published
to PyPI as a normal pure-python library. The C++ code is published as a
source tarball and the Go code is checked back in to the same repo so
that go works properly.

oaktree depends on the python oaktreemodel library, and also on shade.
It implements the server portion of the gRPC service definition.

Currently, oaktree can list and search for flavors, images and floating
ips. Exciting right? Most of the work to expose the rest of the API that
shade can provide at the moment is going to be fairly straightforward -
although in each case figuring out the best mapping will take some care.

We have a few major things that need some good community design. These
are also listed in a todo.rst file in the oaktree repo which is part of
the docs:

  http://oaktree.readthedocs.io/en/latest/

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.

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.

In any case - I'd love help from anyone who thinks this sounds like a
good idea. In a perfect world we'll have something ready for 1.0 by Atlanta.

Join us in #openstack-shade if you want to hack.

Thanks!
Monty


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev