Open Stack

The proposed approach is reasonable.
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 weird that we telling
Neutron to bind port at one place and adding binding information in another.

On Mon, Aug 1, 2016 at 8:13 PM, Jim Rollenhagen <jim at jimrollenhagen.com>
wrote:

> On Mon, Aug 01, 2016 at 08:10:18AM -0400, Jim Rollenhagen wrote:
> > Hey all,
> >
> > Our nova patch for networking[0] got stuck for a bit, because Nova needs
> > to know which network interface is in use for the node, in order to
> > properly set up the port.
> >
> > The code landed for network_interface follows the following order for
> > what is actually used for the node:
> > 1) node.network_interface, if that is None:
> > 2) CONF.default_network_interface, if that isNone:
> > 3) flat, if using neutron DHCP
> > 4) noop, if not using neutron DHCP
> >
> > The API will return None for node.network_interface in the API (GET
> > /v1/nodes/uuid). This won't work for Nova, because Nova can't know what
> > CONF.default_network_interface is.
> >
> > I propose that if a network_interface is not sent in the node-create
> > call, we write whatever the current default is, so that it is always set
> > and not using an implicit value that could change.
> >
> > For nodes that exist before the upgrade, we do a database migration to
> > set network_interface to CONF.default_network_interface (or if that's
> > None, set to flat/noop depending on the DHCP provider).
> >
> > An alternative is to keep the existing behavior, but have the API return
> > whatever interface is actually being used. This keeps the implicit
> > behavior (which I don't think is good), and also doesn't provide a way
> > to find out from the API if the interface is actually set, or if it's
> > using the configurable default.
> >
> > I'm going to go ahead and execute on that plan now, do speak up if you
> > have major objections to it.
>
> By the way, the patch chain to do this is here:
>
> https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1608511
>
> // jim
>
>
> __________________________________________________________________________
> 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/20160802/2542c685/attachment.html>