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 <j...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
