See inline,
On Thu, Nov 21, 2013 at 2:19 AM, Isaku Yamahata <isaku.yamah...@gmail.com>wrote: > On Wed, Nov 20, 2013 at 10:16:46PM -0800, > Gary Duan <gd...@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 > > 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. Thanks, Gary > thanks, > -- > Isaku Yamahata <isaku.yamah...@gmail.com> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev