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".
** 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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
