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