<div dir="ltr">><span style="font-size:12.8px">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.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">So e</span><span style="font-size:12.8px">ither 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.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 21, 2016 at 12:12 PM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 18/11/16 16:47, Clint Byrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Excerpts from Zane Bitter's message of 2016-11-17 18:24:35 -0500:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 15/11/16 09:56, Monty Taylor wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey everybody!<br>
<br>
At this past OpenStack Summit the results of the Interop Challenge were<br>
shown on stage. It was pretty awesome - 17 different people from 17<br>
different clouds ran the same workload. And it worked!<br>
<br>
However, one of the reasons it worked is because they all used the<br>
Ansible modules we wrote that are based on the shade library that<br>
contains the business logic needed to hide vendor differences in clouds.<br>
That means that there IS a fantastic OpenStack interoperability story -<br>
but only if you program in Python. That's less awesome.<br>
</blockquote>
<br>
So I don't want to criticise this effort, because I'm sure that it's<br>
very valuable and worthy &c.<br>
<br>
But it does make me sad that we've so thoroughly given up on the concept<br>
of making the OpenStack APIs themselves interoperable that we're<br>
building an API for our APIs (Yo dawg!) to work around it.<br>
<br>
</blockquote>
<br>
One could argue that this is just the natural order of things in a world<br>
where programmers are disciplined and practice separation of concerns.<br>
</blockquote>
<br></span>
Sure, but the argument would be more convincing if having a bunch of interoperable clouds were not the *entire point* of OpenStack :)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nova's API is for nova. Keystone's is for Keystone. Oaktree's would<br>
simply be for multi-cloud users.<br>
<br>
IMO, it's actually just sad, and I'd like for every project's API to be<br>
evolved for multi-cloud users. But seeing as I've seen so very little<br>
of that actually happening, splitting it out seems like a reasonable<br>
compromise.<br>
</blockquote>
<br></span>
I think we're in agreement.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The problem is that to take advantage of the interoperability benefits<br>
you'll be locked in to a single orchestration tool (Ansible/shade). If<br>
you have a particular reason to use another tool (possibly, ahem, the<br>
one that is an official part of OpenStack and already available in 2/3<br>
of OpenStack clouds... but also Puppet, JuJu, &c.) then you'll have to<br>
choose between whatever feature you wanted there and interoperability.<br>
That's taking "there IS a fantastic OpenStack interoperability story -<br>
but only if you program in Python" and kicking the can one step down the<br>
road (s/program in Python/orchestrate in Ansible). Whereas if we fix the<br>
underlying APIs then *everyone* benefits.<br>
<br>
</blockquote>
<br>
I know Monty said this, but I want to say it again: gRPC is just HTTP/2<br>
+ protobufs. Meaning, it's available to virtually every programming<br>
language in wide usage at this time (the limiting factor being protobuf<br>
implementatoins):<br>
<br>
<a href="https://github.com/google/protobuf/blob/master/docs/third_party.md" rel="noreferrer" target="_blank">https://github.com/google/prot<wbr>obuf/blob/master/docs/third_<wbr>party.md</a><br>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I feel like the entire OpenStack project has, out of a desire not to be<br>
opinionated, consistently failed both our users and operators by<br>
encouraging all sorts of unnecessarily incompatible configurations. Not<br>
to pick on any particular project but e.g. can anyone tell me why<br>
Neutron doesn't automatically come, out of the box, with external<br>
networks called "internet" and "openstack" so that users can create<br>
floating IPs that talk to either the internet or just the control plane,<br>
respectively, on any OpenStack cloud with a single Heat template (or<br>
whatever) without having to paste UUIDs anywhere? What sane reason could<br>
there be to even allow, let alone force, all operators to solve these<br>
problems independently?<br>
<br>
</blockquote>
<br>
Side note: As of right now, I'm pretty sure the only place where you<br>
should have to use network UUID's pasted somewhere is Octavia.<br>
<br>
Also, many OpenStack clouds are not on the internet, and do not want to<br>
give instances access to the control plane. So your example perhaps<br>
needs more thought.<br>
</blockquote>
<br></span>
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.<br>
<br>
(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.)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm sure the infra team can think of 100 pet annoyances like that. So<br>
carry on, but maybe y'all could make a list somewhere of all the<br>
interoperability problems that shade has had to work around and we could<br>
try to make it a priority as a community to address them?<br>
<br>
</blockquote>
<br>
Shade is the python expression of those annoyances. Oaktree would be<br>
exposing that as a gRPC API.<br>
</blockquote>
<br></span>
So what's the governance expression of those annoyances? :)<br>
<br>
cheers,<br>
Zane.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div>