Add spec for neutron-baremetal-compute blueprint
Adds the specification for the neutron physical port extension to integrate baremetal devices into neutron network. Change-Id: Ieea08993f364415c56e3416b1d222101ce5d1ac9
This commit is contained in:
Kevin Benton
parent
4f354e9fd2
commit
36ee7ef12a
|
|
@ -0,0 +1,211 @@
|
|||
===================================================
|
||||
Physical Port Extension for baremetal compute nodes
|
||||
===================================================
|
||||
|
||||
Launchpad blueprint:
|
||||
|
||||
https://blueprints.launchpad.net/neutron/+spec/neutron-baremetal-compute
|
||||
|
||||
|
||||
This blueprint is to introduce the concept of physical ports into Neutron
|
||||
via an extension so baremetal workloads can gain access to Neutron networks.
|
||||
Admins will create the physical port resources with the MAC address
|
||||
of the attached device and port identifier information for the backend.
|
||||
Physical ports will then be assigned to tenants, who will be allowed to
|
||||
associate them to physical networks.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
There is no well-defined way to connect a device not managed by OpenStack
|
||||
directly into a Neutron network. Even if everything is manually configured
|
||||
to setup connectivity, the neutron DHCP agent will not issue addresses to
|
||||
the device attached to the physical port since it doesn't have a corresponding
|
||||
Neutron port.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
To integrate these baremetal devices into Neutron networks, this blueprint
|
||||
introduces the physical port extension. It will add a new mixin class for
|
||||
plugins to use to handle the database accounting for the physical port methods.
|
||||
|
||||
Physical ports are created by admins and then assigned to a tenant for use. The
|
||||
tenant can then assign the physical port to any of the Neutron networks that
|
||||
the tenant can create a Neutron port on.
|
||||
|
||||
When a tenant assigns a physical port to a network, the mixin code will
|
||||
automatically create a Neutron port on that network with the MAC address
|
||||
configured by the admin on the physical port. This will give the DHCP server
|
||||
the necessary information to issue IP addresses to the connected device.
|
||||
|
||||
This keeps the IP allocation for a subnet fully managed by Neutron and enables
|
||||
the visibility of physical devices from neutron. It also paves the way for
|
||||
integrating Ironic with Neutron.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
There isn't a very good alternative right now. To attach a physical device to
|
||||
a Neutron network, the admin has to lookup the VLAN (or other segment
|
||||
identifier) for that network and then manually associate a port to that VLAN.
|
||||
The end device then has to be configured with a static IP in an exclusion range
|
||||
on the Neutron subnet. Tenants then cannot assign the physical device to a
|
||||
different network, disable the port, or see any indication that the device is
|
||||
actually attached to the network.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
For plugins that leverage this extension, it will add a new physical ports
|
||||
table. This table will contain the following fields:
|
||||
|
||||
* id - standard object UUID
|
||||
* name - optional name
|
||||
* port_id - nullable foreign-key reference to associated Neutron port
|
||||
* mac_address - MAC address of attached device to use in Neutron port creation
|
||||
* attachment - an arbitrary identifier for the backend to identify the port
|
||||
|
||||
This will have no impact on the existing data model.
|
||||
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
The following is the API exposed for physical ports.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
RESOURCE_ATTRIBUTE_MAP = {
|
||||
'physical_ports': {
|
||||
'id': {'allow_post': False, 'allow_put': False,
|
||||
'enforce_policy': True,
|
||||
'validate': {'type:uuid': None},
|
||||
'is_visible': True, 'primary_key': True},
|
||||
'tenant_id': {'allow_post': True, 'allow_put': True,
|
||||
'required_by_policy': True,
|
||||
'is_visible': True},
|
||||
'network_id': {'allow_post': True, 'allow_put': True,
|
||||
'enforce_policy': True,
|
||||
'is_visible': True, 'default': None},
|
||||
'port_id': {'allow_post': True, 'allow_put': True,
|
||||
'enforce_policy': True,
|
||||
'validate': {'type:uuid_or_none': None},
|
||||
'is_visible': True, 'default': None},
|
||||
'name': {'allow_post': True, 'allow_put': True,
|
||||
'enforce_policy': True,
|
||||
'validate': {'type:string': None},
|
||||
'is_visible': True, 'default': ''},
|
||||
'description': {'allow_post': True, 'allow_put': True,
|
||||
'enforce_policy': True,
|
||||
'validate': {'type:string': None},
|
||||
'is_visible': True, 'default': ''},
|
||||
'mac_address': {'allow_post': True, 'allow_put': True,
|
||||
'enforce_policy': True,
|
||||
'validate': {'type:mac_address': None},
|
||||
'required_by_policy': True,
|
||||
'is_visible': True},
|
||||
'attachment': {'allow_post': True, 'allow_put': True,
|
||||
'enforce_policy': True,
|
||||
'default': False, 'validate': {'type:string': None},
|
||||
'is_visible': True,
|
||||
'required_by_policy': True}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
The following is the default policy for physical ports.
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
{
|
||||
"create_physical_port": "rule:admin_only",
|
||||
"get_physical_port": "rule:admin_or_owner",
|
||||
"update_physical_port:tenant_id": "rule:admin_only",
|
||||
"update_physical_port": "rule:admin_or_owner",
|
||||
"delete_physical_port": "rule:admin_only"
|
||||
}
|
||||
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
There should be no security impact to Neutron. However, these ports will
|
||||
not have security groups applied to them so users should be warned of this
|
||||
in the documentation.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
N/A
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
The neutron command-line client will be updated with the new physical port
|
||||
CRUD commands.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None to plugins that don't use this extension.
|
||||
|
||||
For plugins that use this extension it will be limited since most
|
||||
this code is only called during physical port CRUD operations.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
N/A
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
If plugin developers want to use this, they will need to enable the extension
|
||||
and use the mixin module.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
kevinbenton
|
||||
|
||||
Other contributors:
|
||||
kanzhe-jiang
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Complete DB mixin model and extension API attributes
|
||||
* Update python neutron client to support the new physical port commands
|
||||
* Implement reference implementation in ML2
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
N/A
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
This may be untestable in tempest by default because it requires physical
|
||||
infrastructure.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
New admin and tenant workflows need to be documented for this extension.
|
||||
It should not impact any other documentation.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
N/A
|
||||
Loading…
Reference in New Issue