Open Stack

Following discussion on IRC, here are my thoughts:

The proposed network_interface allows choosing a "driver" for the 
network part of a node. The values could be something like "nobody", 
"neutron-flat networking" and "neutron-tenant separation".

I think this choice should be left per-node. My reasoning is that you 
could have a bunch of nodes for which you have complete Neutron support, 
through for example an ML2 plugin. These nodes would be configured using 
one of the "neutron-*" modes.

On the other hand, that same Ironic installation could also manage nodes 
for which the switches are unmanaged, or manually configured. In such 
case, you would probably want to use the "nobody" mode.

An important point is to expose this "capability" to Nova as you might 
want to offer nodes with neutron integration differently from "any 
node". I am unsure if the capability should be the value of the 
network_interface or a boolean "neutron integration?". Thoughts?

Mathieu

On 2016-06-28 11:32 AM, Dmitry Tantsur wrote:
> Hi folks!
>
> I was reviewing https://review.openstack.org/317391 and realized I don't
> quite understand why we want to have node.network_interface. What's the
> real life use case for it?
>
> Do we expect some nodes to use Neutron, some - not?
>
> Do we expect some nodes to benefit from network separation, some - not?
> There may be a use case here, but then we have to expose this field to
> Nova for scheduling, so that users can request a "secure" node or a
> "less secure" one. If we don't do that, Nova will pick at random, which
> makes the use case unclear again.
> If we do that, the whole work goes substantially beyond what we were
> trying to do initially: isolate tenants from the provisioning network
> and from each other.
>
> Flexibility it good, but the patches raise upgrade concerns, because
> it's unclear how to provide a good default for the new field. And anyway
> it makes the whole thing much more complex than it could be.
>
> Any hints are welcome.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev