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

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".

** 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


Definitely -1 on using fixed/floating.

#2 - using direct / nat


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?


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to