<div dir="ltr">Dmitry thanks for rising this question!<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 28, 2016 at 6:32 PM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi folks!<br>
<br>
I was reviewing <a href="https://review.openstack.org/317391" rel="noreferrer" target="_blank">https://review.openstack.org/317391</a> and realized I don't quite understand why we want to have node.network_interface. What's the real life use case for it?<br>
<br>
Do we expect some nodes to use Neutron, some - not?<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br>
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.<br>
<br>
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.<br>
<br></blockquote><div><br></div><div>I vote for greater flexibility in future, even there might be some <span id="result_box" class="" lang="en"><span class="">difficulties during upgrades.</span></span>  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Any hints are welcome.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>