[openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation
gduan at varmour.com
Thu Nov 21 20:34:33 UTC 2013
On Thu, Nov 21, 2013 at 2:19 AM, Isaku Yamahata <isaku.yamahata at gmail.com>wrote:
> On Wed, Nov 20, 2013 at 10:16:46PM -0800,
> Gary Duan <gduan at varmour.com> wrote:
> > Hi, Isaku and Edgar,
> > As part of the effort to implement L3 router service type framework, I
> > reworked L3 plugin to introduce a 2-step process, precommit and
> > similar to ML2. If you plan to work on L3 code, we can collaborate.
> Sure, let's collaborate. This is discussion phase at this moment.
> I envisage that our plan will be
> - 1st step: introduce 2-step transition to ML2 plugin
> (and hope other simple plugin will follow)
> - 2nd step: introduce locking protocol or any other mechanism like
> async update similar NVP, or taskflow...
> (design and implementation)
> - Nth step: introduce debugging/test framework
> e.g. insert hooks to trigger artificial sleep or context switch
> in debug mode in order to make race more likely to happen
> Is there any code publicly available?
I will do some clean up and post the patch for discussion.
> > Also, for advanced services such as FW and LBaas, there already is a
> > transition logic in the plugin. For example, a firewall instance can have
> > CREATE, UPDATE and DELETE_PENDING states.
> Oh great! Advanced services have more complex state than core plugin,
> I suppose. Are you aware of further issues?
> Does they require further synchronization in addition to 2-step transition?
> Like lock, serialization, async update...
> Probably we can learn from other projects, nova, cinder...
Advanced service plugins don't have two-step transition today. IMO, If
vendor plugins/drivers don't maintain their own databases for these
services, it might not be urgent to add these steps in the plugin. How to
make sure database and back-end implementation in sync need more thought.
As configuring backend device can be an a-sync process, rollback database
tables can be cumbersome.
> Isaku Yamahata <isaku.yamahata at gmail.com>
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev