[openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help?
zbitter at redhat.com
Mon Nov 21 20:12:45 UTC 2016
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 &c.
>> 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
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, &c.) 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
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 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.)
>> 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? :)
More information about the OpenStack-dev