Tenant networking support for Ironic driver

https://blueprints.launchpad.net/nova/+spec/ironic-networks-support

Currently, Ironic only works on a flat network shared between control plane and tenants. There’s an ongoing effort to allow for arbitrary networks to be connected to Ironic nodes in various configurations.[0][1] Some changes in Nova are required to support this effort.

Problem description

Ironic currently supports a single flat network shared between the control plane and tenants. This causes Ironic to be unusable in multitenant environments, or by users that wish to have an isolated network.

  • Multitenant deployments

  • Deployments that wish to secure the control plane from tenants

Use Cases

  • Deployers that wish to deploy a multitenant environment.

  • Deployers that wish to isolate the control plane from tenants.

  • Users that wish to use isolated networks with Ironic instances.

Proposed change

  • The port-create calls to Neutron, during instance spawn in the Neutron network driver, need to be made with a null binding:host_id. This signals to Neutron that it shouldn’t bind the port yet. To keep the provisioning process away from the tenant network, we need to wait for the deployment to complete before binding the port, which only Ironic can control. As part of the deployment process, Ironic will make a port-update call with: 1) a binding:host_id value of “baremetal:$node_uuid”, and 2) physical switchport information necessary to connect the port. This will happen while the virt driver is waiting for the Ironic node to get a state of “active”.

    To accomplish this, we’ll need to allow the virt driver to define the binding:host_id field. So we’ll need to add a method to the base virt driver class, defaulting to the current value (instance.host), and override that in the ironic driver if the node is using the new networking model (this will be available in the network_provider attribute for the Ironic node).

    The plug_vifs and unplug_vifs methods will also need to be similarly modified to pass the VIF UUID to port groups and ungrouped port objects, rather than all ports.

    (done in Mitaka, but a string change will require a small update. This code also depends on an ironicclient release to have an effect)

  • A BAREMETAL vnic type will be added to the network model to support the BAREMETAL vnic type that was previously added in Neutron.[3]

    (done in Mitaka)

This will support the basic tenant networking support we are building out in Ironic. In the future, we’ll want to support LAG/MLAG/bonds, and multiple networks via VLAN or VXLAN over a pair of bonded NICs (currently Nova enforces a 1:1 mapping of NICs to networks, as in the virtual world NICs can be created on the fly), but these items are outside the scope of this spec.

Alternatives

One alternative is to subclass the NeutronAPI to have it do what we want. This may help make the future work noted above easier. However, as this is used at the API and conductor layers, doing this may break multi-hypervisor deployments.

Data model impact

None.

REST API impact

None.

Security impact

This enables users and deployers to improve the network security for the control plane and Ironic instances.

Notifications impact

None.

Other end user impact

Users will be able to use arbitrary networks with Ironic instances. In the future, we should investigate how to allow the user to specify which physical connection gets connected to which network; however, that is outside the scope of this spec.

Performance Impact

None.

Other deployer impact

None. The flag to use this or not is an attribute on Ironic’s node object. There’s no extra configuration to do on the Nova side to use this feature.

Developer impact

None.

Implementation

Assignee(s)

Primary assignee:

jroll

Other contributors:

Sukhdev lazy_prince

Work Items

  • Cause port-create calls to send a null binding:host_id.

  • Add the BAREMETAL vnic type.

Dependencies

This depends heavily on work being done in Ironic.[0][1]

Note that while this work is not complete at the time of this writing, it has made good progress and is expected to land well before the end of the Mitaka cycle.

Testing

CI jobs that exercise this code are being created as part of the Ironic work; we should also have those jobs run against Nova.

Documentation Impact

There is substantial documentation work to be done on the Ironic side, however there isn’t any work to do on the Nova side.

References

[0] https://blueprints.launchpad.net/ironic/+spec/network-provider

[1] https://blueprints.launchpad.net/ironic/+spec/ironic-ml2-integration

[2] https://blueprints.launchpad.net/neutron/+spec/neutron-ironic-integration

[3] https://review.openstack.org/#/c/197774/

History

Revisions

Release Name

Description

Mitaka

Introduced

Newton

Re-proposed. Removed portgroups support.