Re: [openstack-dev] [ironic] network_interface, defaults, and explicitness

[Devananda van der Veen]

On 08/01/2016 05:10 AM, 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).

Sounds quite reasonable to me.

--deva


__
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

Re: [openstack-dev] [ironic] network_interface, defaults, and explicitness

[Vasyl Saienko]

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 
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

Re: [openstack-dev] [ironic] network_interface, defaults, and explicitness

[Jim Rollenhagen]

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

Re: [openstack-dev] [ironic] network_interface, defaults, and explicitness

[Sam Betts (sambetts)]

On 01/08/2016 13:10, "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.

+1 from me

>
>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.
>
>// jim
>
>[0] https://review.openstack.org/#/c/297895/
>
>__
>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

Re: [openstack-dev] [ironic] network_interface, defaults, and explicitness

[Mathieu Mitchell]

On 2016-08-01 8:10 AM, Jim Rollenhagen wrote:

Hey all,






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.


Works for me and ensures an easier path down the road if that value were 
to change in a deployment.


Mathieu

__
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-dev] [ironic] network_interface, defaults, and explicitness

[Jim Rollenhagen]

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.

// jim

[0] https://review.openstack.org/#/c/297895/

__
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