Allow updating VM port's mac_address
To allow nics on ironic servers to be replaced while retaining the same IP address, we allow unbound or failed VM ports to have their mac_address updated. Change-Id: I83808f7a7f09a7d63a7030843eff74fc364cddcc Implements: blueprint allow-mac-to-be-updated
This commit is contained in:
ChuckC
parent
f94d0fd51c
commit
6ffedebfe3
267
specs/kilo/mac_addr_update.rst
Normal file
267
specs/kilo/mac_addr_update.rst
Normal file
@ -0,0 +1,267 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
============================================
|
||||
Allow compute port mac_address to be updated
|
||||
============================================
|
||||
|
||||
https://blueprints.launchpad.net/neutron/+spec/allow-mac-to-be-updated
|
||||
|
||||
Ironic servers can experience a nic failure which requires nic replacement.
|
||||
The replacement nic can have a new mac address. There is currently no way to
|
||||
handle this situation without the potential of losing the IP address.
|
||||
|
||||
See also bug [2].
|
||||
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
Because the 'mac_address' attribute of port is not updatable, replacing a nic
|
||||
on an ironic server today requires deleting the associated neutron port and
|
||||
creating a new one with the correct mac address. This can result in the server
|
||||
losing its IP address to another port being created at the same time.
|
||||
|
||||
This spec does not seek to retain the same IPv6 SLAAC address when mac address
|
||||
changes. Such addresses are expected to change.
|
||||
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
Change server code to allow the mac_address attribute of the port resource to
|
||||
be updated. Specifically, enable this feature for the ml2 plugin. Any
|
||||
work to be done to other plugins will be addressed in other specs.
|
||||
|
||||
In the base plugin, restrict mac_address update to compute ports only
|
||||
(non-compute ports require more changes and are not covered by the use cases
|
||||
handled here). The use cases don't require an active port, so in the ml2
|
||||
plugin, we require that the port not be 'plugged': vif_type must be
|
||||
BINDING_FAILED or UNBOUND. Note that for ironic servers, vif_type is always
|
||||
BINDING_FAILED, so mac_address can always be changed for those ports. This may
|
||||
at some point be viewed as a bug however, so any fix to that bug will need to
|
||||
account for this feature. For 'normal' VMs, the life cycle of binding:vif_type
|
||||
depends on the backend. The l2pop mech driver is updated to change the fdb
|
||||
table entries appropriately.
|
||||
|
||||
In the OVS L2 agent, send a gratuitous arp when a mac_address change is
|
||||
detected.
|
||||
|
||||
The allowed_address_pairs extension allows for the mac_address of any pair to
|
||||
default to port.mac_address. This implies that there are cases where updating
|
||||
the port's mac_address should also update the allowed_address_pair mac_address.
|
||||
|
||||
|
||||
Data Model Impact
|
||||
-----------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
REST API Impact
|
||||
---------------
|
||||
|
||||
Modify the 'allow_put' property of the 'mac_address' attribute in the 'ports'
|
||||
entry of the RESOURCE_ATTRIBUTE_MAP from False to True. The policy.json file
|
||||
is modified to add rules for "update_port:mac_address" - the same rules are
|
||||
used as for "create_port:mac_address" except network owner is not allowed.
|
||||
|
||||
|
||||
Security Impact
|
||||
---------------
|
||||
|
||||
To be conservative for now, this feature will be restricted by default to the
|
||||
following.
|
||||
|
||||
* admin role
|
||||
|
||||
* advsvc role
|
||||
|
||||
The user can adjust policy.json as always, if desired.
|
||||
|
||||
|
||||
Notifications Impact
|
||||
--------------------
|
||||
|
||||
Introduces a new case where notifications are issued, but does not add a new
|
||||
notification or modify or remove any existing notification.
|
||||
|
||||
|
||||
Other End User Impact
|
||||
---------------------
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
The performance impact when mac_address is changed during a port update are
|
||||
characterized in the following list.
|
||||
|
||||
* The impact should be the same as that of changing the ip address.
|
||||
|
||||
* For dvr environments, adds the overhead of VM arp table updates for all
|
||||
routers on the network.
|
||||
|
||||
|
||||
IPv6 Impact
|
||||
-----------
|
||||
|
||||
No IPv6-specific issues are expected. When a mac address changes, the SLAAC
|
||||
address, if any, will change also, but since such addresses are dynamic, that
|
||||
should be fine. Domain name servers will need to start vending the new
|
||||
address, and the current code should handle the AAAA record update to OpenStack
|
||||
DHCP servers. If the subnet's DHCP is not enabled, the propagation of the new
|
||||
address to external DNS servers is out of scope. The link local address also
|
||||
changes, but that is also fine.
|
||||
|
||||
|
||||
Other Deployer Impact
|
||||
---------------------
|
||||
|
||||
Deployers can now replace nics in ironic servers.
|
||||
|
||||
|
||||
Developer Impact
|
||||
----------------
|
||||
|
||||
Non-ml2 plugin developers need to decide whether mac_address updates can be
|
||||
allowed or are desirable in their environment. The normal development process
|
||||
should take place to deal with the fact that the neutron api and the base
|
||||
plugin now allow mac address update.
|
||||
|
||||
|
||||
Community Impact
|
||||
----------------
|
||||
|
||||
Integrates well with ironic: in addition to nic replacement, some nics have
|
||||
changeable mac addresses, so the ability to change the mac_address of a port
|
||||
seems useful.
|
||||
|
||||
There hasn't been much discussion yet, aside from review comments against the
|
||||
implementation.
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
1. If fixed_ips were a separate resource (similar to floating_ips, and vaguely
|
||||
referred to in [4]), then the tenant could retain ownership of ip address while
|
||||
the port was deleted and re-created with the new mac address. This would
|
||||
require a large change to the data model, which may not be justified by the
|
||||
requirements of this spec. This also puts the burden of relating ip address
|
||||
and mac address on the client, along with the various failure scenarios that
|
||||
would have to be handled without the benefit of transactions. Seems like a
|
||||
bigger win to do the proposed relatively small change in the server and remove
|
||||
some complexity from clients.
|
||||
|
||||
2. Another thought was to use DHCP client id instead of mac address in the dhcp
|
||||
protocol. Then the mac address becomes irrelevant to the ip address lookup,
|
||||
and replacing the card would have no affect on the IP address assigned.
|
||||
However, based on a quick discussion with the Ironic team [3], there is a hard
|
||||
need to have the port mac_address match the hardware's mac address.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
ChuckC (Chuck Carlino)
|
||||
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
Work items related to neutron core.
|
||||
|
||||
1. Review [1]
|
||||
|
||||
2. Baremetal scenario testing to cover nic replacement
|
||||
|
||||
3. allowed_address_pairs support
|
||||
|
||||
4. API tests
|
||||
|
||||
Vendor plugin work items are out of scope.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Tempest Tests
|
||||
-------------
|
||||
|
||||
Add tempest test cases to cover mad address update.
|
||||
|
||||
* VM mac address update verifying connectivity
|
||||
|
||||
* baremetal nic replacement
|
||||
|
||||
|
||||
Functional Tests
|
||||
----------------
|
||||
|
||||
Add tests updating a port's mac_address and validate that the following
|
||||
are appropriately updated/notified.
|
||||
|
||||
* DHCP agents
|
||||
|
||||
* security group rules
|
||||
|
||||
* allowed_address_pairs
|
||||
|
||||
|
||||
API Tests
|
||||
---------
|
||||
|
||||
Since this feature involves an api change, we plan to add tests to validate the
|
||||
update of port's mac_address. If, at the time of implementation, neutron API
|
||||
tests include negative test cases and tests of policy.json, then those will be
|
||||
added for this feature as well.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Need to document that it is now permitted to update the mac_address of
|
||||
an unbound or failed VM port.
|
||||
|
||||
User Documentation
|
||||
------------------
|
||||
|
||||
The following documents and sections may need updating.
|
||||
|
||||
* Cloud Administrator Guide
|
||||
|
||||
- Core Networking API features
|
||||
|
||||
* Neutron/APIv2-specification (Port table)
|
||||
|
||||
Developer Documentation
|
||||
-----------------------
|
||||
|
||||
None.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] https://review.openstack.org/112129
|
||||
|
||||
[2] https://bugs.launchpad.net/neutron/+bug/1341268
|
||||
|
||||
[3] http://lists.openstack.org/pipermail/openstack-dev/2014-November/050329.html
|
||||
|
||||
[4] https://blueprints.launchpad.net/neutron/+spec/neutron-ipam
|
||||
Loading…
Reference in New Issue
Block a user