[openstack-dev] [ironic] network_interface, defaults, and explicitness
vsaienko at mirantis.com
Tue Aug 2 06:41:42 UTC 2016
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>
> On Mon, Aug 01, 2016 at 08:10:18AM -0400, Jim Rollenhagen wrote:
> > Hey all,
> > Our nova patch for networking 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:
> // jim
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev