[openstack-dev] [ironic] Routed Networks, flat driver and physical network awareness

Sam Betts (sambetts) sambetts at cisco.com
Wed Jun 28 10:17:19 UTC 2017

Thanks for the interest in Ironic routed networks support! I think some of our on-going work should solve the issues you’ve described here.

On the ironic service side the major feature required for routed networks support is physical network awareness, patches for this are progressing well and can be found here: https://review.openstack.org/#/q/topic:bug/1666009

This feature will allow ironic to be aware of which neutron physnet each baremetal node NIC is connected too, which lets us make intelligent decisions when mapping neutron ports to physical NICs on the baremetal server, and which provides us with required information to feed the segment to host mapping data into neutron.

The additional pieces which will be required to make routed networks work exist the new openstack/networking-baremetal repo, which is where we will be storing any neutron drivers and agents required to make ironic neutron networking operate correctly.

The first puzzle piece is a new ML2 driver which provides the functionality for binding baremetal vnic type ports into statically/manually configured (flat) networks:

With this driver, the flat network interface in Ironic will no longer incorrectly do the port binding for flat networks by binding the neutron port to the nova host that requested the ironic deploy, and instead it will be able to use the baremetal vnic type and set the binding host id to the ironic node uuid.

The second puzzle piece is to do with populating the host to physical network mapping information in neutron so that it can calculate the segment to host mapping information, that is done by using the neutron L2 agent RPC API to push this information up into neutron, and the current proposed solution for that can be found here: https://review.openstack.org/#/c/456235/

Once this is in place then neutron will be aware about which physical network segments each baremetal is plugged into and by populating nova placement’s API aggregates (like it does for normal nova compute hosts) will ensure that scheduling gives you a valid baremetal node when you request a baremetal instance on a routed network.

Any help and/or reviews of this work would be most appreciated, 

Sam Betts (sambetts)

On 28/06/2017, 10:31, "Harald Jensås" <hjensas at redhat.com> wrote:

    With the following Neutron patches recently merged, it is now possible
    to provide DHCP service to instances on remote routed networks that
    have a dhcp forwarder configured.
    This enables provisioning of baremetal machines on remote routed
    networks as well. Removing the need to deploy ironic
    conductor/inspector etc with local connection to each routed network
    However with the flat driver this does not work, because the flat
    driver bind neutron ports to the node running ironic-conductor service,
    e.g 'nova_host_id'. Not to the actual baremetal node. (Ref: https://git
    The result of binding to the 'nova_host_id' causes this error for
    baremetal nodes on the remote routed network segment.
    INFO ironic.conductor.task_manager [req-11f5c864-cc1a-49ee-b224-
    a6695c1a9678 87f6dc660b1f43f79efa4355080e118c
    6a8453039524487ca0bbf191cdc6317d - default default] Node f19ecc51-c8ec-
    4d34-a349-206a5ae97ed2 moved to provision state "deploy fail
    ed" from state "deploying"; target provision state is "active":
    NetworkError: Unable to set binding:host_id for neutron port 5e674173-
    32d9-4ec9-be2a-7f2b3aa02336. Error: Host ironic-
    conductor.node.example.com is not connected to a segment where the
    existing fixed_ips on port 5e6741
    73-32d9-4ec9-be2a-7f2b3aa02336 will function given the routed network
    I can workaround this by not binding the port:
    $ sudo sed -i \
        s/'binding:host_id': host_id/'binding:host_id': None/" \
    I can see good progress on the phys-net aware spec. But with the flat
    driver this will not help, as the nova_host_id is used for binding. Not
    the ironic baremetal node uuid.
    What would be a good way forward here?
     - Change the flat driver to not bind the port?
     - Change the flat driver to bind using the ironic node uuid, and rely
    on phys-net info being populated in Neutron? (Requieres: baremetal
    neutron agent https://review.openstack.org/#/c/456235/ + several
    changes related to phys-net)
     - Another driver? 'flat-routed' that does one of the above?
     - Keep the flat driver, but register the ironic-conductor as a
    separate host in neutron and populate phys-nets in neutron for this
    'ironic_host_id' with all networks available on the baremetal nodes
    ironic is managing?
    Is there already a plan? Other options?
    |Harald Jensås        |  irc: hjensas
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list