[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