[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