1d674825eb
IPv4 DAD is non-existent in Linux or its failure is silent, so we never needed to catch and ignore it. On the other hand IPv6 DAD failure is explicit, hence comes this change. This of course leaves the metadata service dead on hosts where duplicate address detection failed. But if we catch the DADFailed exception and delete the address, at least other functions of the dhcp-agent should not be affected. With this the IPv6 isolated metadata service is not redundant, which is the best we can do without a redesign. Also document the promised service level of isolated metadata. Added additional tests for the metadata driver as well. Conflicts: neutron/tests/unit/agent/metadata/test_driver.py conflict withf430cd0072
Change-Id: I6b544c5528cb22e5e8846fc47dfb8b05f70f975c Partial-Bug: #1953165 (cherry picked from commit2aee961ab6
) (cherry picked from commit071255f098
) (cherry picked from commit1c615281f7
) (cherry picked from commitdefb6018f3
)
17 lines
911 B
YAML
17 lines
911 B
YAML
---
|
|
issues:
|
|
- |
|
|
The high availability of metadata service on isolated networks is limited
|
|
or non-existent. IPv4 metadata is redundant when the DHCP agent managing
|
|
it is redundant, but recovery is tied to the renewal of the DHCP lease,
|
|
making most recoveries very slow. IPv6 metadata is not redundant at all
|
|
as the IPv6 metadata address can only be configured in a single place at
|
|
a time as it is link-local. Multiple agents trying to configure it will
|
|
generate an IPv6 duplicate address detection failure.
|
|
|
|
Administrators may observe the IPv6 metadata address in "dadfailed" state
|
|
in the DHCP namespace for this reason, which is only an indication it is
|
|
not highly available. Until a redesign is made to the isolated metadata
|
|
service there is not a better deployment option. See `bug 1953165
|
|
<https://bugs.launchpad.net/neutron/+bug/1953165>`_ for information.
|