Bug 1046782

Summary:	[RFE][neutron]: Eventually Consistent DHCP Agent
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	openstack-neutron	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED UPSTREAM	QA Contact:	Ofer Blaut <oblaut>
Severity:	high	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	chrisw, lpeer, markmc, mnewby, nyechiel, oblaut, yeylon
Target Milestone:	---	Keywords:	CodeChange, FutureFeature, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/neutron/+spec/eventually-consistent-dhcp-agent
Whiteboard:	upstream_milestone_none upstream_status_deferred upstream_definition_obsolete
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-19 11:20:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description RHOS Integration 2013-12-26 23:09:10 UTC

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

Comment 2 Roey Dekel 2014-02-03 12:10:38 UTC

How can we test this properly? Which are the main break points here?

Comment 3 Maru Newby 2014-02-08 04:57:37 UTC

(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.

Comment 6 Nir Yechiel 2014-02-19 09:08:30 UTC

Upstream status was changed to 'deferred' and the blueprint is no longer targeted to Icehouse. Updating this BZ to reflect that

Comment 7 lpeer 2015-03-19 11:20:57 UTC

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.