[openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation

Gary Duan gduan at varmour.com
Thu Nov 21 20:34:33 UTC 2013

See inline,

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,
> Hi.
> > As part of the effort to implement L3 router service type framework, I
> have
> > reworked L3 plugin to introduce a 2-step process, precommit and
> postcommit,
> > 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
> >
> https://blueprints.launchpad.net/neutron/+spec/l3-router-service-type-framework
> 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
> state
> > transition logic in the plugin. For example, a firewall instance can have
> 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.


> thanks,
> --
> Isaku Yamahata <isaku.yamahata at gmail.com>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131121/3464d56d/attachment.html>

More information about the OpenStack-dev mailing list