Re: [openstack-dev] [neutron] [OVN] Tempest API / Scenario tests and OVN metadata

[Anil Venkata]

How to override tempest tests in neutron or networking-ovn repo?

Thanks
Anil

On Mon, Apr 9, 2018 at 8:26 PM, Lucas Alvares Gomes 
wrote:

> Hi,
>
> > Another idea is to modify test that it will:
> > 1. Check how many ports are in tenant,
> > 2. Set quota to actual number of ports + 1 instead of hardcoded 1 as it
> is now,
> > 3. Try to add 2 ports - exactly as it is now,
> >
> > I think that this should be still backend agnostic and should fix this
> problem.
> >
>
> Great idea! I've gave it a go and proposed it at
> https://review.openstack.org/559758
>
> Cheers,
> Lucas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Neutron L3 agent/Keepalived

[Anil Venkata]

Which neutron branch you are using?
May be this bug https://bugs.launchpad.net/neutron/+bug/1723848 is similar
and
corresponding https://review.openstack.org/#/c/512179/ patch was merged in
u/s
and backported to Ocata and pike branches.

Please also check these [1] relevant patches
[1]
https://review.openstack.org/#/q/topic:bug/1597461+(status:open+OR+status:merged)

Thanks
Anilvenkata

On Mon, Dec 4, 2017 at 6:38 PM, Anna Taraday 
wrote:

> Please, file a bug about that on https://bugs.launchpad.net/neutron/+bugs
> with tag "l3-ha".
>
> On Thu, Nov 30, 2017 at 6:00 AM Ajay Kalambur (akalambu) <
> akala...@cisco.com> wrote:
>
>> I noticed that this happens when the router HA interface shows status:
>> Down what can cause the ha interface to do down
>>
>> Ajay
>>
>>
>> From: Ajay Kalambur 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Wednesday, November 29, 2017 at 4:14 PM
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: [openstack-dev] [neutron] Neutron L3 agent/Keepalived
>>
>> Hi
>> I have a case where after running the system for a while I see that
>> floating ip association API gets accepted and no Errors in neutron l3 logs
>> But when I go into the qrouter namespace and check the qg- interface the
>> floating ip is not added
>> Also the keepalived.conf is not updated and SIGUP of the keepalived
>> process is not done
>>
>> So whats the place to look in this case.  What is the flow in neutron l3
>> agent who adds the floating ip to the qg- interface
>> I see the router update notification received
>> Key log snippet attached. As you can see SIGUP of keepalived is missing
>> and also I confirmed keepalived configs are not updated
>>
>>
>> 2017-11-29 14:32:08.883 78 DEBUG oslo_messaging._drivers.amqpdriver [-]
>> received message with unique_id: b3886b998c3049e799170bb5351300d1
>> __call__ /usr/lib/python2.7/site-packages/oslo_messaging/_
>> drivers/amqpdriver.py:269
>> 2017-11-29 14:32:08.885 78 DEBUG neutron.agent.l3.agent
>> [req-6c505d32-2d1a-4392-8ea3-0bb888397b9e e759eebecc4648b4964d4ecf439dc0ff
>> 13b4f6fb188048ba9bbf211344e3342f - - -] Got routers updated notification
>> :[u'a1a59e5f-d74e-404d-a3aa-1667c4442aed'] routers_updated
>> /usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py:413
>> 2017-11-29 14:32:08.886 78 DEBUG neutron.agent.l3.agent [-] Starting
>> router update for a1a59e5f-d74e-404d-a3aa-1667c4442aed, action None,
>> priority 0 _process_router_update /usr/lib/python2.7/site-
>> packages/neutron/agent/l3/agent.py:487
>> 2017-11-29 14:32:08.886 78 DEBUG oslo_messaging._drivers.amqpdriver [-]
>> CALL msg_id: 92eb015c8c84489681b1efbe949fab8b exchange 'neutron' topic
>> 'q-l3-plugin' _send /usr/lib/python2.7/site-packages/oslo_messaging/_
>> drivers/amqpdriver.py:568
>>
>> 2017-11-29 14:32:09.571 78 DEBUG oslo_messaging._drivers.amqpdriver [-]
>> received reply msg_id: 92eb015c8c84489681b1efbe949fab8b __call__
>> /usr/lib/python2.7/site-packages/oslo_messaging/_
>> drivers/amqpdriver.py:416
>> 2017-11-29 14:32:09.571 78 DEBUG neutron.callbacks.manager [-] Notify
>> callbacks [] for router, before_update _notify_loop /usr/lib/python2.7/site-
>> packages/neutron/callbacks/manager.py:142
>> 2017-11-29 14:32:09.572 78 DEBUG neutron.agent.l3.router_info [-] process
>> router updates process /usr/lib/python2.7/site-packages/neutron/agent/l3/
>> router_info.py:1105
>> 2017-11-29 14:32:09.572 78 DEBUG neutron.agent.linux.utils [-] Running
>> command (rootwrap daemon): ['ip', 'netns', 'exec',
>> 'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'find',
>> '/sys/class/net', '-maxdepth', '1', '-type', 'l', '-printf', '%f ']
>> execute_rootwrap_daemon /usr/lib/python2.7/site-
>> packages/neutron/agent/linux/utils.py:105
>> 2017-11-29 14:32:09.709 78 DEBUG neutron.agent.linux.utils [-] Exit code:
>> 0 execute /usr/lib/python2.7/site-packages/neutron/agent/linux/
>> utils.py:150
>> 2017-11-29 14:32:09.710 78 DEBUG oslo_concurrency.lockutils [-] Lock
>> "l3-agent-pd" acquired by "neutron.agent.linux.pd.sync_router" :: waited
>> 0.000s inner /usr/lib/python2.7/site-packages/oslo_concurrency/
>> lockutils.py:270
>> 2017-11-29 14:32:09.710 78 DEBUG oslo_concurrency.lockutils [-] Lock
>> "l3-agent-pd" released by "neutron.agent.linux.pd.sync_router" :: held
>> 0.000s inner /usr/lib/python2.7/site-packages/oslo_concurrency/
>> lockutils.py:282
>> 2017-11-29 14:32:09.710 78 DEBUG neutron.agent.linux.utils [-] Running
>> command (rootwrap daemon): ['ip', 'netns', 'exec',
>> 'qrouter-a1a59e5f-d74e-404d-a3aa-1667c4442aed', 'find',
>> '/sys/class/net', '-maxdepth', '1', '-type', 'l', '-printf', '%f ']
>> execute_rootwrap_daemon /usr/lib/python2.7/site-
>> packages/neutron/agent/linux/utils.py:105
>> 2017-11-29 14:32:09.845 78 DEBUG neutron.agent.linux.utils [-] Exit code:
>> 0 execute 

Re: [openstack-dev] [Neutron][ovn] networking-ovn core team update

[Anil Venkata]

Congrats Daniel

On 01-Dec-2017 10:22 PM, "Jakub Libosvar"  wrote:

> Congratulations! Very well deserved! :)
>
> On 01/12/2017 17:45, Lucas Alvares Gomes wrote:
> > Hi all,
> >
> > I would like to welcome Daniel Alvarez to the networking-ovn core team!
> >
> > Daniel has been contributing with the project for a good time already
> > and helping *a lot* with reviews and code.
> >
> > Welcome onboard man!
> >
> > Cheers,
> > Lucas
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Call for help with in-tree tempest scenario test failures

[Anil Venkata]

I will work on DVR+HA migration jobs.

Thanks
Anilvenkata

On Fri, Aug 11, 2017 at 2:40 AM, Sławek Kapłoński 
wrote:

> Hello,
>
> I’m still checking this QoS scenario test and I found something strange
> IMHO.
> For example, almost all failed tests from last 2 days were executed on
> nodes with names like:
> * ubuntu-xenial-2-node-citycloud-YYY- - on those nodes almost (or
> even all) all scenario tests was failed due to failed SSH connection to
> instance,
> * ubuntu-xenial-2-node-rax-iad- - on those nodes QoS test was failed
> because of timeout during reading data
>
> I’m noob in gate tests and how it’s exactly working so my conclusions can
> be completely wrong but maybe those issues are related somehow to some
> cloud providers which provides infrastructure for tests?
> Maybe someone more experienced could take a look on that and help me? Thx
> in advance.
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
> > Wiadomość napisana przez Ihar Hrachyshka  w dniu
> 03.08.2017, o godz. 23:40:
> >
> > Thanks for those who stepped in (Armando and Slawek).
> >
> > We still have quite some failures that would benefit from initial log
> > triage and fixes. If you feel like in this feature freeze time you
> > have less things to do, helping with those scenario failures would be
> > a good way to contribute to the project.
> >
> > Thanks,
> > Ihar
> >
> > On Fri, Jul 28, 2017 at 6:02 AM, Sławek Kapłoński 
> wrote:
> >> Hello,
> >>
> >> I will try to check QoS tests in this job.
> >>
> >> —
> >> Best regards
> >> Slawek Kaplonski
> >> sla...@kaplonski.pl
> >>
> >>
> >>
> >>
> >>> Wiadomość napisana przez Jakub Libosvar  w dniu
> 28.07.2017, o godz. 14:49:
> >>>
> >>> Hi all,
> >>>
> >>> as sending out a call for help with our precious jobs was very
> >>> successful last time and we swept all Python 3 functional from Neutron
> >>> pretty fast (kudos the the team!), here comes a new round of failures.
> >>>
> >>> This time I'm asking for your help  >>> poster here> with gate-tempest-dsvm-neutron-dvr-multinode-scenario
> >>> non-voting job. This job has been part of check queue for a while and
> is
> >>> very very unstable. Such job covers scenarios like router dvr/ha/legacy
> >>> migrations, qos, trunk and dvr. I went through current failures and
> >>> created an etherpad [1] with categorized failures and logstash queries
> >>> that give you latest failures with given particular tests.
> >>>
> >>> If you feel like doing troubleshooting and sending fixes for gates,
> >>> please pick one test and write down your name to the test.
> >>>
> >>> Thanks to all who are willing to participate.
> >>>
> >>> Have a great weekend.
> >>> Jakub
> >>>
> >>>
> >>> [1]
> >>> https://etherpad.openstack.org/p/neutron-dvr-multinode-
> scenario-gate-failures
> >>>
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][L3][HA] 2 masters after reboot of node

[Anil Venkata]

Thanks Kevin. I added it to get_router_ids [1], which is called when
full_sync flag is set(i.e when agent is AGENT_REVIVED, updated or started)
and  not in get_routers/sync_routers.

[1] https://review.openstack.org/#/c/470905/

On Sat, May 27, 2017 at 2:54 AM, Kevin Benton <ke...@benton.pub> wrote:

> 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 <anilvenk...@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 <ke...@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" <anilvenk...@redhat.com> wrote:
>>>
>>>> On Fri, May 26, 2017 at 6:14 PM, Kevin Benton <ke...@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 <anilvenk...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][L3][HA] 2 masters after reboot of node

[Anil Venkata]

Thanks Kevin, Agree with you. I will try to implement this suggestion.

On Fri, May 26, 2017 at 7:01 PM, Kevin Benton <ke...@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" <anilvenk...@redhat.com> wrote:
>
>> On Fri, May 26, 2017 at 6:14 PM, Kevin Benton <ke...@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 <anilvenk...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][L3][HA] 2 masters after reboot of node

[Anil Venkata]

On Fri, May 26, 2017 at 6:14 PM, Kevin Benton <ke...@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 <anilvenk...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][L3][HA] 2 masters after reboot of node

[Anil Venkata]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Alternative approaches for L3 HA

[Anil Venkata]

On Thu, Feb 23, 2017 at 12:10 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

> I have updated the spreadsheet. In the case of RH/RDO we're using the same
> architecture
> in the case of HA, pacemaker is not taking care of those anymore since the
> HA-NG implementation.
>
> We let systemd take care to restart the services that die, and we worked
> with the community
> to make sure that agents and services are robust in case of dependent
> services (database, rabbitmq
> ) failures, to make sure they reconnect and continue when those become
> available.
>
> On Wed, Feb 22, 2017 at 11:28 AM, Adam Spiers  wrote:
>
>> Kosnik, Lubosz  wrote:
>> > About success of RDO we need to remember that this deployment utilizes
>> Peacemaker and when I was working on this feature and even I spoke with
>> Assaf this external application was doing everything to make this solution
>> working.
>> > Peacemaker was responsible for checking external and internal
>> connectivity. To detect split brain. Elect master, even keepalived was
>> running but Peacemaker was automatically killing all services and moving
>> FIP.
>> > Assaf - is there any change in this implementation in RDO? Or you’re
>> still doing everything outside of Neutron?
>> >
>> > Because if RDO success is build on Peacemaker it means that yes,
>> Neutron needs some solution which will be available for more than RH
>> deployments.
>>
>> Agreed.
>>
>> With help from others, I have started an analysis of some of the
>> different approaches to L3 HA:
>>
>> https://ethercalc.openstack.org/Pike-Neutron-L3-HA
>>
>> (although I take responsibility for all mistakes ;-)
>>
>

Did you test with this patch https://review.openstack.org/#/c/255237/  ? It
was merged in newton cycle.
With this patch, HA+L2pop doesn't depend on control plane during fail over,
hence failover should be faster(same as without l2pop).


>
>> It would be great if someone from RH or RDO could provide information
>> on how this RDO (and/or RH OSP?) solution based on Pacemaker +
>> keepalived works - if so, I volunteer to:
>>
>>   - help populate column E of the above sheet so that we can
>> understand if there are still remaining gaps in the solution, and
>>
>>   - document it (e.g. in the HA guide).  Even if this only ended up
>> being considered as a shorter-term solution, I think it's still
>> worth documenting so that it's another option available to
>> everyone.
>>
>> Thanks!
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Enable arp_responder without l2pop

[Anil Venkata]

On Wed, Feb 22, 2017 at 6:19 PM, Thomas Morin <thomas.mo...@orange.com>
wrote:

> Hi Anil,
>
> Tue Feb 21 2017 22:47:46 GMT-0500 (EST), Anil Venkata:
>
>> Currently arp_resonder can enabled only if l2pop is enabled.
>>
>> Can we have arp_responder feature enabled without l2pop(i.e Remove the
>> dependency between arp_responder and l2_pop)?
>>
>>
> I agree that it would be useful.
> networking-bgpvpn ovs/bagpipe driver is relying on arp_responder, and
> hence currently draws this dependency on l2pop (not an issue I find, but
> still an artefact rather than a design decision).
>
> Also setup arp_responder on OVS integration bridge(and not on br-tun)?
>>
>>
> While relevant, I think this is not possible until br-int allows to match
> the network a packet belongs to (the ovsdb port tags don't let you do that
> until the packet leaves br-int with a NORMAL action).
> Ajo has told me yesterday that the OVS firewall driver uses registers
> precisely to do that. Making this generic (and not specific to the OVS
> firewall driver) would be a prerequisite before you can add ARP responder
> rules in br-int.
>
>
Thanks Thomas. Spoke to Ajo on this. He said we can follow above suggestion
i.e do the same what firewall driver is doing  in br-int, or wait till OVS
flow extension is implemented(but this will take time as lack of resources)


> I think this question (of where to put the ARP responder rules) also
> relates to https://review.openstack.org/#/c/320439/ .
>
> -Thomas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Enable arp_responder without l2pop

[Anil Venkata]

Hi All

Currently arp_resonder can enabled only if l2pop is enabled.

Can we have arp_responder feature enabled without l2pop(i.e Remove the
dependency between arp_responder and l2_pop)?
Also setup arp_responder on OVS integration bridge(and not on br-tun)?.

To enable arp_responder, we only need port's MAC and IP Address and no
tunnel ip(So no need for l2pop).
Currently agents use l2pop notifications to create ARP entries. With the
new approach, agents can use
port events(create, update and delete) to create ARP entry and without
l2pop notifications.

The advantages with this approach for both linuxbridge and OVS agent -
1) Users can enable arp_responder without l2pop
2) Support ARP for distributed router ports(DVR and HA).
Currently, ARP is not added for these ports.
This is a fix for https://bugs.launchpad.net/neutron/+bug/1661717

As we are not dependent on l2pop, we can  create ARP entries on OVS
integration bridge.

Advantages for OVS agent, if ARP entries are setup on integration
bridge(br-int) rather than on tunneling bridge(br-tun)
1) It enables arp_responder for all network types(vlans, vxlan, etc)
arp_responder based on l2pop is supported for only overlay networks.
2) ARP can be resolved within br-int.
3) ARP packets for local ports(ports connected to same br-int) will be
resolved
   in br-int without broadcasting to actual ports connected to br-int.


Any suggestions?

Also submitted bug [1] for this.

[1] https://bugs.launchpad.net/neutron/+bug/1518392

Thanks
Anil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [third party][neutron] - OpenDaylight CI failing for past 6 days

[Anil Venkata]

Hi All

Last successful build on OpenDaylight CI( 
https://jenkins.opendaylight.org/ovsdb/job/openstack-gerrit/ ) was 6 days back.
After that, OpenDaylight CI Jenkins job is failing for all the patches.

Can we remove the voting rights for the OpenDaylight CI until it is fixed?

Thanks
Anil.Venakata

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev