<div dir="ltr">The proposed approach is reasonable.<br>Just a small adding. I think for a longterm concept it would be good to avoid setting binding_host_id in ironic virt_driver. We should force users to set it when 'binding_profile' is updated. It looks <span class="gmail-short_text" id="gmail-result_box" lang="en"><span class="gmail-alt-edited">weird</span></span> that we telling Neutron to bind port at one place and adding binding information in another.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 8:13 PM, Jim Rollenhagen <span dir="ltr"><<a href="mailto:jim@jimrollenhagen.com" target="_blank">jim@jimrollenhagen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Aug 01, 2016 at 08:10:18AM -0400, Jim Rollenhagen wrote:<br>
> Hey all,<br>
><br>
> Our nova patch for networking[0] got stuck for a bit, because Nova needs<br>
> to know which network interface is in use for the node, in order to<br>
> properly set up the port.<br>
><br>
> The code landed for network_interface follows the following order for<br>
> what is actually used for the node:<br>
> 1) node.network_interface, if that is None:<br>
> 2) CONF.default_network_interface, if that isNone:<br>
> 3) flat, if using neutron DHCP<br>
> 4) noop, if not using neutron DHCP<br>
><br>
> The API will return None for node.network_interface in the API (GET<br>
> /v1/nodes/uuid). This won't work for Nova, because Nova can't know what<br>
> CONF.default_network_interface is.<br>
><br>
> I propose that if a network_interface is not sent in the node-create<br>
> call, we write whatever the current default is, so that it is always set<br>
> and not using an implicit value that could change.<br>
><br>
> For nodes that exist before the upgrade, we do a database migration to<br>
> set network_interface to CONF.default_network_interface (or if that's<br>
> None, set to flat/noop depending on the DHCP provider).<br>
><br>
> An alternative is to keep the existing behavior, but have the API return<br>
> whatever interface is actually being used. This keeps the implicit<br>
> behavior (which I don't think is good), and also doesn't provide a way<br>
> to find out from the API if the interface is actually set, or if it's<br>
> using the configurable default.<br>
><br>
> I'm going to go ahead and execute on that plan now, do speak up if you<br>
> have major objections to it.<br>
<br>
</div></div>By the way, the patch chain to do this is here:<br>
<a href="https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1608511" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1608511</a><br>
<span class="HOEnZb"><font color="#888888"><br>
// jim<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>