Open Stack

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 <zbitter at redhat.com
> <mailto:zbitter at redhat.com>> 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 &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
>         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, &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
>         <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
>     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? :)
> 
>     cheers,
>     Zane.
> 
> 
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>