Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150316/f8110bcc/attachment.html>