Open Stack

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.