Open Stack

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. :)

On Fri, May 26, 2017 at 7:53 AM, Anil Venkata <anilvenkata at redhat.com>
wrote:

> Thanks Kevin, Agree with you. I will try to implement this suggestion.
>
> On Fri, May 26, 2017 at 7:01 PM, Kevin Benton <kevin at benton.pub> wrote:
>
>> 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>
>>>> wrote:
>>>>
>>>>> This is regarding https://bugs.launchpad.net/neutron/+bug/1597461
>>>>> Earlier to fix this, we added code [1] 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 [2]),
>>>>> though l2 agent might not have wired[3] 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?
>>>>>
>>>>> [1] https://review.openstack.org/#/c/357458/
>>>>> [2] https://bugs.launchpad.net/neutron/+bug/1597461/comments/26
>>>>> [3] l2 agent wiring means setting up ovs flows on br-tun to make port
>>>>> usable
>>>>>
>>>>> Thanks
>>>>> Anilvenkata
>>>>>
>>>>> ____________________________________________________________
>>>>> ______________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>>> enstack.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.op
>>>> enstack.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.op
>>> enstack.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:unsubscrib
>> e
>> 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/20170526/302946ba/attachment.html>