<div dir="ltr">I recommend a completely new RPC endpoint to trigger this behavior that the L3 agent calls before sync routers. Don't try to add it to sync routers which is already quite complex. :)</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 7:53 AM, Anil Venkata <span dir="ltr"><<a href="mailto:anilvenkata@redhat.com" target="_blank">anilvenkata@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Kevin, Agree with you. I will try to implement this suggestion.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 7:01 PM, Kevin Benton <span dir="ltr"><<a href="mailto:kevin@benton.pub" target="_blank">kevin@benton.pub</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Just triggering a status change should just be handled as a port update on the agent side which shouldn't interrupt any existing flows. So an l3 agent reboot should be safe in this case. </div><div class="m_2318389698704910602HOEnZb"><div class="m_2318389698704910602h5"><div class="gmail_extra"><br><div class="gmail_quote">On May 26, 2017 6:06 AM, "Anil Venkata" <<a href="mailto:anilvenkata@redhat.com" target="_blank">anilvenkata@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 26, 2017 at 6:14 PM, Kevin Benton <span dir="ltr"><<a href="mailto:kevin@benton.pub" target="_blank">kevin@benton.pub</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Perhaps when the L3 agent starts up we can have it explicitly set the port status to DOWN for all of the HA ports on that node. Then we are guaranteed that when they go to ACTIVE it will be because the L2 agent has wired the ports.</div><div class="gmail_extra"><br></div></blockquote><div> </div><div>Thanks Kevin. Will it create dependency of dataplane on controlplane. For example, if the node is properly configured(l2 agent wired up, keepalived configured, VRRP exchange happening) but user just restarted only l3 agent, then with the suggestion we won't break l2 connectivity(leading to multiple HA masters) by re configuring again? </div><div><br></div><div>Or is there a way server can detect that node(not only agent) is down and set port status?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_2318389698704910602m_-7847292296302407515m_5102484264779338242h5">On Fri, May 26, 2017 at 5:27 AM, Anil Venkata <span dir="ltr"><<a href="mailto:anilvenkata@redhat.com" target="_blank">anilvenkata@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_2318389698704910602m_-7847292296302407515m_5102484264779338242h5"><div dir="ltr">This is regarding <a href="https://bugs.launchpad.net/neutron/+bug/1597461" target="_blank">https://bugs.launchp<wbr>ad.net/neutron/+bug/1597461</a><div>Earlier to fix this, we added code [1] to spawn keepalived only when HA network port status is active. </div><div><br></div><div>But, on reboot, node will get HA network port's status as ACTIVE from server(please see comment [2]),</div><div>though l2 agent might not have wired[3] the port, resulting in spawning keepalived. Any suggestions</div><div>how l3 agent can detect that l2 agent has not wired the port and then avoid spawning keepalived? </div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/357458/" target="_blank">https://review.openstack.o<wbr>rg/#/c/357458/</a><br></div><div>[2] <a href="https://bugs.launchpad.net/neutron/+bug/1597461/comments/26" target="_blank">https://bugs.launchpad.net<wbr>/neutron/+bug/1597461/comments<wbr>/26</a></div><div>[3] l2 agent wiring means setting up ovs flows on br-tun to make port usable</div><div> </div><div>Thanks</div><div>Anilvenkata</div></div>
<br></div></div>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br></blockquote></div><br></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br></blockquote></div><br></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br></blockquote></div></div>
</div></div><br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>