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

Isaku Yamahata isaku.yamahata at gmail.com
Thu Nov 21 10:19:16 UTC 2013


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?


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

thanks,
-- 
Isaku Yamahata <isaku.yamahata at gmail.com>



More information about the OpenStack-dev mailing list