Hello, I read blueprint which You send but I don't know how it should solve for example problems like can be in l2pop mechanism. It send message to fanout cast and forget about it. There is no any exception in port_update_postcommit operation but message can be not consumed by some agents (or maybe I'm wrong and it couldn't happen?) and then this agent is not synced with neutron db.
-- Pozdrawiam / Best regards Sławek Kapłoński sla...@kaplonski.pl Dnia poniedziałek, 16 marca 2015 11:05:45 Mohammad Banikazemi pisze: > It is perhaps worth mentioning that there is an effort to implement a > generic synchronization mechanism (between Neutron and backend > controllers/devices) in the ML2 plugin [1]. A possible framework for its > eventual implementation is in an early discussion/proof-of-concept WIP > state [2]. > > -Mohammad > > [1] https://blueprints.launchpad.net/neutron/+spec/ml2-driver-sync > [2] https://review.openstack.org/#/c/154333/ > > > > From: Cory Benfield <cory.benfi...@metaswitch.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 03/16/2015 04:48 AM > Subject: Re: [openstack-dev] [neutron] Generic question about > synchronizing neutron agent on compute node with DB > > On Sun, Mar 15, 2015 at 22:37:59, Sławek Kapłoński wrote: > > Maybe good idea for the beginning could be to implement some periodic > > task > > called from agent to check db config and compare it with real state on > > host? > > What do You think? Or maybe I'm competly wrong with such idea and it > > should be > > done in different way? > > This is almost exactly what we do in our Calico ML2 driver. Each of our > agents will periodically request its complete state from a neutron-server > node and will ensure that its local state matches that expected state. This > interval is configurable, to allow administrators to make a trade-off > between DB/network load and convergence time. > > With reliable transport this is in principle almost never needed (messages > only really get lost on agent crash, and the agent will resynchronize when > it starts back up anyway), but it provides assurances that the fabric is > capable of bringing itself into consistency without administrator > intervention. > > Having similar function in other neutron agents would be valuable for the > exact same reasons, but do bear in mind the potentially increased load this > kind of resynchronization can place on databases and servers. > > Cory > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
