Cloned from launchpad blueprint https://blueprints.launchpad.net/neutron/+spec/eventually-consistent-dhcp-agent. Description: The DHCP agent has a number of design flaws in its state synchronization strategy that have the potential to negatively impact reliability. Notifications may be processed in the wrong order, there is no way to detect whether a notification is stale, and there is no guarantee that missed notifications will be detected. Any of these may result in inconsistencies between db and agent-local state that could impact VM connectivity. Explicit notification ordering should be possible and the agent should use this ordering to ensure eventual consistency. Specification URL (additional information): https://docs.google.com/document/d/1TD48EUZU7CJFh3iCLgelqnpBFgZoO6-n4HCmIyO_PfU/edit?usp=sharing
How can we test this properly? Which are the main break points here?
(In reply to Roey Dekel from comment #2) > How can we test this properly? Which are the main break points here? Validating the reliability of the dhcp agent will not be possible via black-box testing. My intention is to ensure that known failure modes (out-of-order, missing and stale notifications) are checked in unit tests, and the efforts to test neutron scalability will ensure that those results hold up at scale.
Upstream status was changed to 'deferred' and the blueprint is no longer targeted to Icehouse. Updating this BZ to reflect that
This RFE was automatically opened to track status of upstream development. At this point we see no reason to keep track of this in Red Hat bugzilla, thus closing it.