[openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB
slawek at kaplonski.pl
Mon Mar 16 20:16:23 UTC 2015
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
slawek at 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 . A possible framework for its
> eventual implementation is in an early discussion/proof-of-concept WIP
> state .
>  https://blueprints.launchpad.net/neutron/+spec/ml2-driver-sync
>  https://review.openstack.org/#/c/154333/
> From: Cory Benfield <Cory.Benfield at metaswitch.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at 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
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev