[openstack-dev] [ironic] why do we need setting network driver per node?
Mathieu Mitchell
mmitchell at internap.com
Tue Jun 28 16:08:16 UTC 2016
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
More information about the OpenStack-dev
mailing list