Open Stack

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