Open Stack

Dmitry thanks for rising this question!

On Tue, Jun 28, 2016 at 6:32 PM, Dmitry Tantsur <dtantsur at redhat.com> 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?
>

Neutron already provides great flexibility by ML2 drivers. Multi hardware
environments can be managed without any problems if Ironic uses Neutron, by
using different ML2 driver for different hardware types.

With multitenancy there might be cases when user don't want to use Neutron
and Neutron ML2 drivers. In this case only specifying network_interface per
node may give full flexibility in multivendor environments.


> 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.
>
>
I vote for greater flexibility in future, even there might be some difficulties
during upgrades.


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160629/46f97622/attachment.html>