Hi Tan,

Please help me to understand your bug. I think it is as follows:

- Ironic node has two ports.
- Nova instance has a single NIC, so creates only a single Neutron port.
- There is no way to control which ironic port neutron maps its port to.

Is that correct?

I have attached our internal fix for bug 1405131 to the bug for discussion. I am currently at the ironic mid-cycle meetup and am discussing with Sylvain Bauza from the Nova team how to approach getting a fix upstream.

Mark Goddard | Software Engineer, HPC Systems.
<email address hidden>
178-180 Hotwell Road | Bristol | BS8 4RP | UK | www.cray.com

             


-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Tan Lin
Sent: 04 February 2015 13:28
To: Mark Goddard
Subject: [Bug 1405131] Re: Ports cannot be mapped to networks

Hi Mark,

I also work on a similar bug on this https://bugs.launchpad.net/ironic/+bug/1412454,
It would be great if you can propose your fix.

Tan

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1405131

Title:
  Ports cannot be mapped to networks

Status in OpenStack Bare Metal Provisioning Service (Ironic):
  New
Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  I have a cluster of bare metal nodes managed by Icehouse OpenStack on
  CentOS 6.5. I'm using nova, ironic and neutron. The nodes each have a
  1G management network interface and a 40G high speed data network
  interface. These interfaces are registered with their MAC addresses as
  ironic ports. There is a single flat neutron network for management
  and a single flat neutron network for the high speed network.

  When booting a (baremetal) nova instance, if the instance's networks
  are specified by their network ID, there is no way (to my knowledge)
  to guarantee a mapping between interface and network. In 50% of cases,
  I will end up with a neutron port on the management network, with the
  MAC address of the node's 40G NIC, and vice versa. The implication of
  this is that DHCP address assignment fails, and the instance fails to
  provision with the following error message:

  2014-12-23 05:03:20.877 227052 ERROR ironic.conductor.manager [-]
  Timeout reached when waiting callback for node 49f8b733-525d-
  44a2-ae19-596b19aa5d1a

  My workaround is to manually create neutron ports for each network
  interface, specifying a MAC address and the appropriate neutron
  network. These ports are then referenced when booting an instance,
  instead of specifying a network ID. This workaround is not ideal, in
  particular because it only works when the nodes are pets (as opposed
  to cattle).

  Based on my browsing of the nova source, I think the point of ill
  decision occurs at
  https://github.com/openstack/nova/blob/06c537fbe5bb4ac5a3012642c899df815872267c/nova/network/neutronv2/api.py#L270.

  Simple minded, misguided half solution - tag the ironic ports with
  some metadata, such as the provider:physical_network tag of the
  neutron network to which they are attached. This can be used in nova
  to select an appropriate HW port for each of the instance's networks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic/+bug/1405131/+subscriptions