[openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB

Sławek Kapłoński slawek at kaplonski.pl
Mon Mar 16 20:05:12 UTC 2015


Hello,

Thanks. I didn't find it before.
When we will upgrade our infra we will see if this problem will still present. 
I hope that this was due to that bug maybe and will be fixed then :) 

--
Pozdrawiam / Best regards
Sławek Kapłoński
slawek at kaplonski.pl

Dnia poniedziałek, 16 marca 2015 00:14:57 Mathieu Rohon pisze:
> Hi slawek,
> 
> may be you're hitting this l2pop bug :
> https://bugs.launchpad.net/neutron/+bug/1372438
> 
> On Sun, Mar 15, 2015 at 11:37 PM, Sławek Kapłoński <slawek at kaplonski.pl>
> 
> wrote:
> > Hello,
> > 
> > Dnia niedziela, 15 marca 2015 17:45:05 Salvatore Orlando pisze:
> > > On 14 March 2015 at 11:19, Sławek Kapłoński <slawek at kaplonski.pl> wrote:
> > > > Hello,
> > > > 
> > > > I'm using ovs agents with L2 population mechanism in ML2 plugin. I
> > 
> > noticed
> > 
> > > > that sometimes agents don't receive proper RPC to add new vxlan tunnel
> > > > openflow rules and then vxlan network between some compute nodes not
> > > > working.
> > > > I'm now using still havana release but want to upgrade to Juno. I was
> > > > checking
> > > > Juno code in l2 population mech driver and ovs plugin and I didn't
> > > > find
> > > > anything like periodic check if openflow rules are proper set or maybe
> > > > resynced.
> > > > Maybe it would be also good idea to add something like that to ovs
> > 
> > agent?
> > 
> > > It would surely be a good idea to add some form of reliability into
> > > communications between server and agents.
> > > So far there are still several instances where the server sends a "fire
> > 
> > and
> > 
> > > forget" notification to the agent, and does not take any step to ensure
> > 
> > the
> > 
> > > state change associated with that notification has been actually applied
> > 
> > to
> > 
> > > the agent. This applies also to some messages from the agent side, such
> > 
> > as
> > 
> > > status change notifications.
> > 
> > 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 something that can be beneficial any neutron implementation
> > > which
> > > depends on one or more agents, not just for those using the ovs/linux
> > > bridge agents with the l2-population driver.
> > 
> > Probably yes, but I had this problem only with this l2-population driver
> > so
> > far and that's why I wrote about it :)
> > 
> > --
> > Pozdrawiam / Best regards
> > Sławek Kapłoński
> > slawek at kaplonski.pl
> > 
> > > Salvatore
> > > 
> > > > --
> > > > Pozdrawiam / Best regards
> > > > Sławek Kapłoński
> > > > slawek at kaplonski.pl
> > > > 
> > > > Dnia piątek, 13 marca 2015 11:18:28 YAMAMOTO Takashi pisze:
> > > > > > However, I briefly looked through the L2 agent code and didn't see
> > 
> > a
> > 
> > > > > > periodic task to resync the port information to protect from a
> > 
> > neutron
> > 
> > > > > > server that failed to send a notification because it crashed or
> > 
> > lost
> > 
> > > > its
> > > > 
> > > > > > amqp connection. The L3 agent has a period sync routers task that
> > > > 
> > > > helps in
> > > > 
> > > > > > this regard. Maybe another neutron developer more familiar with
> > 
> > the L2
> > 
> > > > > > agent can chime in here if I'm missing anything.
> > > > > 
> > > > > i don't think you are missing anything.
> > > > > periodic sync would be a good improvement.
> > > > > 
> > > > > YAMAMAOTO Takashi
> > 
> > __________________________________________________________________________
> > 
> > > > > OpenStack Development Mailing List (not for usage questions)
> > > > 
> > > > > Unsubscribe:
> > > > OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list