Open Stack

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.

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