[openstack-dev] [neutron][L3][HA] 2 masters after reboot of node
kevin at benton.pub
Fri May 26 13:31:24 UTC 2017
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.
On May 26, 2017 6:06 AM, "Anil Venkata" <anilvenkata at redhat.com> wrote:
> On Fri, May 26, 2017 at 6:14 PM, Kevin Benton <kevin at benton.pub> wrote:
>> 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.
> 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?
> Or is there a way server can detect that node(not only agent) is down and
> set port status?
>> On Fri, May 26, 2017 at 5:27 AM, Anil Venkata <anilvenkata at redhat.com>
>>> This is regarding https://bugs.launchpad.net/neutron/+bug/1597461
>>> Earlier to fix this, we added code  to spawn keepalived only when HA
>>> network port status is active.
>>> But, on reboot, node will get HA network port's status as ACTIVE from
>>> server(please see comment ),
>>> though l2 agent might not have wired the port, resulting in spawning
>>> keepalived. Any suggestions
>>> how l3 agent can detect that l2 agent has not wired the port and
>>> then avoid spawning keepalived?
>>>  https://review.openstack.org/#/c/357458/
>>>  https://bugs.launchpad.net/neutron/+bug/1597461/comments/26
>>>  l2 agent wiring means setting up ovs flows on br-tun to make port
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev