Open Stack

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