[openstack-dev] [api][neutron][nova][Openstack-operators][interop] Time for a bikeshed - help me name types of networking
Doug Hellmann
doug at doughellmann.com
Mon May 15 16:51:49 UTC 2017
Excerpts from Jay Pipes's message of 2017-05-15 12:40:17 -0400:
> On 05/14/2017 01:02 PM, Monty Taylor wrote:
> > ** Bikeshed #1 **
> >
> > Are "internal" and "external" ok with folks as terms for those two ideas?
>
> Yup, ++ from me on the above.
>
> > ** Bikeshed #2 **
> >
> > Anybody have a problem with the key name "network-models"?
>
> They're not network models. They're access/connectivity policies. :)
>
> > (Incidentally, the idea from this is borrowed from GCE's
> > "compute#accessConfig" [0] - although they only have one model in their
> > enum: "ONE_TO_ONE_NAT")
> >
> > In a perfect future world where we have per-service capabilities
> > discovery I'd love for such information to be exposed directly by
> > neutron.
>
> I actually don't see this as a Neutron thing. It's the *workload*
> connectivity expectations that you're describing, not anything to do
> with networks, subnets or ports.
>
> So, I think actually Nova would be a better home for this capability
> discovery, for similar reasons why get-me-a-network was mostly a Nova
> user experience...
>
> So, I suppose I'd prefer to call this thing an "access policy" or
> "access model", optionally prefixing that with "network", i.e. "network
> access policy".
We have enough things overloading the term "policy." Let's get out
a thesaurus for this one. ;-)
Doug
>
> > ** Bikeshed #3 **
> >
> > What do we call the general concepts represented by fixed and floating
> > ips? Do we use the words "fixed" and "floating"? Do we instead try
> > something else, such as "direct" and "nat"?
> >
> > I have two proposals for the values in our enum:
> >
> > #1 - using fixed / floating
> >
> > ipv4-external-fixed
> > ipv4-external-floating
> > ipv4-internal-fixed
> > ipv4-internal-floating
> > ipv6-fixed
>
> Definitely -1 on using fixed/floating.
>
> > #2 - using direct / nat
> >
> > ipv4-external-direct
> > ipv4-external-nat
> > ipv4-internal-direct
> > ipv4-internal-nat
> > ipv6-direct
>
> I'm good with direct and nat. +1 from me.
>
> > On the other hand, "direct" isn't exactly a commonly used word in this
> > context. I asked a ton of people at the Summit last week and nobody
> > could come up with a better term for "IP that is configured inside of
> > the server's network stack". "non-natted", "attached", "routed" and
> > "normal" were all suggested. I'm not sure any of those are super-great -
> > so I'm proposing "direct" - but please if you have a better suggestion
> > please make it.
>
> The other problem with the term "direct" is that there is already a vNIC
> type of the same name which refers to a guest's vNIC using a host
> passthrough device.
>
> So, maybe non-nat or no-nat would be better? Or hell, make it a boolean
> is_nat or has_nat if we're really just referring to whether an IP is
> NATted or not?
>
> Best,
> -jay
>
More information about the OpenStack-dev
mailing list