Open Stack

On 05/15/2017 11:51 AM, Doug Hellmann wrote:
> 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. ;-)

Good points from both of you - thank you.

Access Model would be fine by me - it's very similar to the GCE term 
which is "access config".

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

We need more words. :)

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

I think the questions are:

"Does this cloud support accessing this server using NAT?"
"Does this cloud support accessing this server without NAT?"

(which your suggestion would carry)

However, I'm skiddish on calling it "nat" and "not-nat" - because as a 
user not coming from a background where servers are accessed via nat - 
I'm not sure I'd think to express my desire as "can I have a not-nat 
please?" But maybe that's just the world we live in - where normal 
"Internet" connectivity is only known as "isn't natted"...