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