Re-propose ironic-networks-support for Newton
Previously-approved: Mitaka Change-Id: I1bac6a625d750c970915cf5f13d058cee14f6f7a Spec for blueprint ironic-networks-support
This commit is contained in:
Jim Rollenhagen
committed by
Matt Riedemann
Matt Riedemann
parent
f4752e13a9
commit
c46075b9d4
216
specs/newton/approved/ironic-networks-support.rst
Normal file
216
specs/newton/approved/ironic-networks-support.rst
Normal file
@@ -0,0 +1,216 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
===========================================
|
||||
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
|
||||
|
||||
* Deployments that wish to use "advanced" network configurations such as LAG,
|
||||
MLAG, bonding, VLAN/VXLAN
|
||||
|
||||
Use Cases
|
||||
----------
|
||||
|
||||
* Deployers that wish to deploy a multitenant environment.
|
||||
|
||||
* Deployers that wish to isolate the control plane from tenants.
|
||||
|
||||
* Deployers that wish to deploy baremetal hosts using "advanced" network
|
||||
configurations such as LAG, MLAG, bonding, VLAN/VXLAN.
|
||||
|
||||
* 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)
|
||||
|
||||
* Ironic now has a concept of "port groups"[1], which is a single logical
|
||||
connection comprised of multiple physical NICs; used in LAG and MLAG
|
||||
configurations. These are a first-class citizen in the API. The
|
||||
`macs_for_instance` method in the ironic driver needs to be changed to report
|
||||
MACs for both port groups and ungrouped ports. For example::
|
||||
|
||||
# the old method
|
||||
[port.address for port in get_ports_for_node()]
|
||||
|
||||
# the new method
|
||||
([port.address for port in get_ungrouped_ports_for_node()] +
|
||||
[portgroup.address for portgroup in get_portgroups_for_node()])
|
||||
|
||||
* 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 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.
|
||||
|
||||
* Make changes to the Ironic driver to handle Ironic "port groups" in addition
|
||||
to Ironic "ports".
|
||||
|
||||
|
||||
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
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - Mitaka
|
||||
- Introduced
|
||||
* - Newton
|
||||
- Re-proposed
|
||||
Reference in New Issue
Block a user