<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 14 March 2015 at 11:19, 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>
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 working.<br>
I'm now using still havana release but want to upgrade to Juno. I was 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></blockquote><div><br></div><div>It would surely be a good idea to add some form of reliability into communications between server and agents.</div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Salvatore</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Pozdrawiam / Best regards<br>
Sławek Kapłoński<br>
<a href="mailto:slawek@kaplonski.pl" target="_blank">slawek@kaplonski.pl</a><br>
<br>
Dnia piątek, 13 marca 2015 11:18:28 YAMAMOTO Takashi pisze:<br>
<div><div>> > 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 its<br>
> > amqp connection. The L3 agent has a period sync routers task that helps in<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>
> 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></div>