Re: [openstack-dev] [devstack][infra] pip vs psutil

[Slawomir Kaplonski]

Hi,

I just wanted to ask if there is any ongoing work on 
https://bugs.launchpad.net/devstack/+bug/1763966 to fix grenade failures? It 
looks that e.g. all grenade jobs in neutron are broken currently :/

> Wiadomość napisana przez Gary Kotton  w dniu 15.04.2018, 
> o godz. 13:32:
> 
> Hi,
> The gate is currently broken with https://launchpad.net/bugs/1763966. 
> https://review.openstack.org/#/c/561427/ Can unblock us in the short term. 
> Any other ideas?
> Thanks
> Gary
> __
> 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

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com


__
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] [devstack][infra] pip vs psutil

[Slawomir Kaplonski]

Right. Thx Gary :)

> Wiadomość napisana przez Gary Kotton  w dniu 16.04.2018, 
> o godz. 09:14:
> 
> Hi,
> I think that we need https://review.openstack.org/561471 until we have a 
> proper solution.
> Thanks
> Gary
> 
> On 4/16/18, 10:13 AM, "Slawomir Kaplonski"  wrote:
> 
>Hi,
> 
>I just wanted to ask if there is any ongoing work on 
> https://bugs.launchpad.net/devstack/+bug/1763966 to fix grenade failures? It 
> looks that e.g. all grenade jobs in neutron are broken currently :/
> 
>> Wiadomość napisana przez Gary Kotton  w dniu 15.04.2018, 
>> o godz. 13:32:
>> 
>> Hi,
>> The gate is currently broken with https://launchpad.net/bugs/1763966. 
>> https://review.openstack.org/#/c/561427/ Can unblock us in the short term. 
>> Any other ideas?
>> Thanks
>> Gary
>> __
>> 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
> 
>— 
>Best regards
>Slawek Kaplonski
>skapl...@redhat.com
> 
> 
>__
>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

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com


__
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][dynamic routing] RYU Breaks lower constraints

[Slawomir Kaplonski]

I just sent a patch to bump Ryu version in Neutron’s requirements to fix lower 
constraints job there also: https://review.openstack.org/#/c/561579/


> Wiadomość napisana przez Gary Kotton  w dniu 16.04.2018, 
> o godz. 09:13:
> 
> Please see https://review.openstack.org/561443
> 
> On 4/16/18, 2:31 AM, "IWAMOTO Toshihiro"  wrote:
> 
>On Sun, 15 Apr 2018 21:02:42 +0900,
>Gary Kotton wrote:
>> 
>> [1  ]
>> [1.1  ]
>> Hi,
>> That sounds reasonable. I wonder if the RYU folk can chime in here.
>> Thanks
> 
>I don't fully understand the recent g-r change yet, but
>I guess neutron-dynamic-routing should  also have ryu>=4.24.
>I'll check this tommorrow.
> 
>> From: Akihiro MOTOKI 
>> Reply-To: OpenStack List 
>> Date: Sunday, April 15, 2018 at 12:43 PM
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [neutron][dynamic routing] RYU Breaks lower 
>> constraints
>> 
>> Gary,
>> 
>> I think this is caused by the recent pip change and pip no longer cannot 
>> import pip from code. The right solution seems to bump the minimum version 
>> of ryu.
>> 
>> Thought?
>> 
>> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128939.html
>> 
>> Akihiro
>> 
>> 2018/04/15 午後6:06 "Gary Kotton" 
>> mailto:gkot...@vmware.com>>:
>> Hi,
>> It seems like ther RYU import is breaking the project:
>> 
>> 
>> 2018-04-15 
>> 08:41:34.654681
>>  | ubuntu-xenial | b'--- import errors ---\nFailed to import test module: 
>> neutron_dynamic_routing.tests.unit.services.bgp.driver.ryu.test_driver\nTraceback
>>  (most recent call last):\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py",
>>  line 456, in _find_test_path\nmodule = 
>> self._get_module_from_name(name)\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py",
>>  line 395, in _get_modu
> le_from_name\n__import__(name)\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/tests/unit/services/bgp/driver/ryu/test_driver.py",
>  line 21, in \nfrom ryu.services.protocols.bgp import 
> bgpspeaker\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/services/protocols/bgp/bgpspeaker.py",
>  line 21, in \nfrom ryu.lib.packet.bgp import (\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/__init__.py 
> ower-constraints/lib/python3.5/site-packages/ryu/lib/packet/__init__.py>", 
> line 6, in \nfrom . import (ethernet, arp, icmp, icmpv6, ipv4, 
> ipv6, lldp, mpls, packet,\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ethernet.py",
>  line 18, in \nfrom . import vlan\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/vlan.py",
>  line 21, in \nfrom . import ipv4\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ipv4.py 
> ttp://git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ipv4.py>",
>  line 23, in \nfrom . import tcp\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/tcp.py",
>  line 24, in \nfrom . import bgp\n  File 
> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.

Re: [openstack-dev] [neutron][dynamic routing] RYU Breaks lower constraints

[Slawomir Kaplonski]

Hi,

Just for information to all who sends patches for Neutron.
Patch [1] is now merged so if in Your patch lower-constraints job is still 
failing with error like in this thread, please rebase Your patch on top of [1] 
instead of just rechecking which probably will not help.

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

> Wiadomość napisana przez Slawomir Kaplonski  w dniu 
> 16.04.2018, o godz. 12:41:
> 
> I just sent a patch to bump Ryu version in Neutron’s requirements to fix 
> lower constraints job there also: https://review.openstack.org/#/c/561579/
> 
> 
>> Wiadomość napisana przez Gary Kotton  w dniu 16.04.2018, 
>> o godz. 09:13:
>> 
>> Please see https://review.openstack.org/561443
>> 
>> On 4/16/18, 2:31 AM, "IWAMOTO Toshihiro"  wrote:
>> 
>>   On Sun, 15 Apr 2018 21:02:42 +0900,
>>   Gary Kotton wrote:
>>> 
>>> [1  ]
>>> [1.1  ]
>>> Hi,
>>> That sounds reasonable. I wonder if the RYU folk can chime in here.
>>> Thanks
>> 
>>   I don't fully understand the recent g-r change yet, but
>>   I guess neutron-dynamic-routing should  also have ryu>=4.24.
>>   I'll check this tommorrow.
>> 
>>> From: Akihiro MOTOKI 
>>> Reply-To: OpenStack List 
>>> Date: Sunday, April 15, 2018 at 12:43 PM
>>> To: OpenStack List 
>>> Subject: Re: [openstack-dev] [neutron][dynamic routing] RYU Breaks lower 
>>> constraints
>>> 
>>> Gary,
>>> 
>>> I think this is caused by the recent pip change and pip no longer cannot 
>>> import pip from code. The right solution seems to bump the minimum version 
>>> of ryu.
>>> 
>>> Thought?
>>> 
>>> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128939.html
>>> 
>>> Akihiro
>>> 
>>> 2018/04/15 午後6:06 "Gary Kotton" 
>>> mailto:gkot...@vmware.com>>:
>>> Hi,
>>> It seems like ther RYU import is breaking the project:
>>> 
>>> 
>>> 2018-04-15 
>>> 08:41:34.654681<http://logs.openstack.org/43/561443/3/check/openstack-tox-lower-constraints/087c168/job-output.txt.gz#_2018-04-15_08_41_34_654681>
>>>  | ubuntu-xenial | b'--- import errors ---\nFailed to import test module: 
>>> neutron_dynamic_routing.tests.unit.services.bgp.driver.ryu.test_driver\nTraceback
>>>  (most recent call last):\n  File 
>>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py<http://git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py>",
>>>  line 456, in _find_test_path\nmodule = 
>>> self._get_module_from_name(name)\n  File 
>>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py<http://git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/unittest2/loader.py>",
>>>  line 395, in _get_modu
>>le_from_name\n__import__(name)\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/tests/unit/services/bgp/driver/ryu/test_driver.py<http://git.openstack.org/openstack/neutron-dynamic-routing/neutron_dynamic_routing/tests/unit/services/bgp/driver/ryu/test_driver.py>",
>>  line 21, in \nfrom ryu.services.protocols.bgp import 
>> bgpspeaker\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/services/protocols/bgp/bgpspeaker.py<http://git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/services/protocols/bgp/bgpspeaker.py>",
>>  line 21, in \nfrom ryu.lib.packet.bgp import (\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/__init__.py<http://git.openstack.org/openstack/neutron-dynamic-routing/.tox/l
>>
>> ower-constraints/lib/python3.5/site-packages/ryu/lib/packet/__init__.py>", 
>> line 6, in \nfrom . import (ethernet, arp, icmp, icmpv6, ipv4, 
>> ipv6, lldp, mpls, packet,\n  File 
>> "/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/ethernet.py<http://git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/

[openstack-dev] [neutron] Sum up about "Enable mutable configuration" goal in Neutron

[Slawomir Kaplonski]

Hi,

I was working to implement goal [1] in Neutron and it’s now done with [2].
I also checked with code search if other related to neutron projects will need 
any changes.
I looked with [3] for projects which might need such changes. According to this 
list it looks that projects which may require 
some changes are:

openstack/neutron-lbaas
openstack/networking-cisco
openstack/networking-dpm
openstack/networking-infoblox
openstack/networking-l2gw
openstack/networking-lagopus
openstack/neutron-dynamic-routing
openstack/networking-avaya
openstack/networking-6wind

Based on mail [4] I updated also neutron-dynamic-routing project [5] and 
proposed a patch for neutron-lbaas [6] but it will probably not be merged as 
neutron-lbaas is deprecated.

If You are maintainer of one of other projects from list above (or other 
related to neutron) please take care of this goal on Your side.

[1] 
https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
[2] https://review.openstack.org/#/c/554259/
[3] 
http://codesearch.openstack.org/?q=service.launch&i=nope&files=&repos=networking-6wind,networking-ale-omniswitch,networking-arista,networking-avaya,networking-bagpipe,networking-baremetal,networking-bgpvpn,networking-bigswitch,networking-brocade,networking-calico,networking-cisco,networking-cumulus,networking-dpm,networking-edge-vpn,networking-extreme,networking-fortinet,networking-fujitsu,networking-generic-switch,networking-generic-switch-tempest-plugin,networking-gluon,networking-h3c,networking-hpe,networking-huawei,networking-hyperv,networking-icc,networking-infoblox,networking-l2gw,networking-l2gw-tempest-plugin,networking-lagopus,networking-lenovo,networking-midonet,networking-mlnx,networking-nec,networking-odl,networking-onos,networking-opencontrail,networking-ovn,networking-ovs-dpdk,networking-peregrine,networking-plumgrid,networking-powervm,networking-sfc,networking-spp,networking-vpp,networking-vsphere,networking-zte,networking-zvm,neutron-classifier,neutron-dynamic-routing,neutron-fwaas,neutron-fwaas-dashboard,neutron-lbaas,neutron-lbaas-dashboard,neutron-lib,neutron-specs,neutron-tempest-plugin,neutron-vpnaas,neutron-vpnaas-dashboard
[4] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129137.html
[5] https://review.openstack.org/#/c/559309/
[6] https://review.openstack.org/#/c/559412/

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com


__
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] Gate-failure bugs spring cleaning

[Slawomir Kaplonski]

Hi Neutrinos,

There is time for some spring cleaning now so I went through list of Neutron 
bugs with „gate-failure” tag https://tinyurl.com/y826rccx 
I mark some of them as incomplete if there was not hits of same errors in last 
30 days. Please reopen them with proper comment if You think that it is still 
valid bug or if You will spot similar error in some recent test runs.

About some of them I’m not sure if are still valid so please check it and maybe 
update comment or close it if it’s already fixed somehow :)

Below detailed summary of bugs which I checked:

I removed Neutron from affected projects:
* https://bugs.launchpad.net/tempest/+bug/1660612 

I marked as incomplete:
* https://bugs.launchpad.net/neutron/+bug/1687027
* https://bugs.launchpad.net/neutron/+bug/1693931
* https://bugs.launchpad.net/neutron/+bug/1676966

Bugs which needs check of owner:
* https://bugs.launchpad.net/neutron/+bug/1711463 - @Miguel, is it still valid? 
Can we close it?
* https://bugs.launchpad.net/neutron/+bug/1717302 - @Brian, no action since 
2017-12-12, is it failing still?

Bug which IMO should be reported against Cinder instead of Neutron, can someone 
check and confirm that:
* https://bugs.launchpad.net/neutron/+bug/1726462 - Is it related to Neutron 
really, IMO it look like error with Cinder and it happens also in other than 
neutron jobs, like „devstack-platform-opensuse-tumbleweed” and 
„nova-multiattach” for example

Still valid bugs probably:
* https://bugs.launchpad.net/neutron/+bug/1693950 - not exactly same error but 
same tests failures I found recently so I think it is still valid to check
* https://bugs.launchpad.net/neutron/+bug/1756301 - @Miguel: Can You check and 
confirm that this is still valid
* https://bugs.launchpad.net/neutron/+bug/1569621 - should be fixed by 
https://review.openstack.org/#/c/562220/ - @Jakub can You confirm that?

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com


__
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] Is there any way to recheck only one job?

[Slawomir Kaplonski]

Hi,

I wonder if there is any way to recheck only one type of job instead of 
rechecking everything.
For example sometimes I have to debug some random failure in specific job type, 
like „neutron-fullstack” and I want to collect some additional data or test 
something. So in such case I push some „Do not merge” patch and waits for job 
result - but I really don’t care about e.g. pep8 or UT results so would be good 
is I could run (recheck) only job which I want. That could safe some resources 
for other jobs and speed up my tests a little as I could be able to recheck 
only my job faster :)

Is there any way that I can do it with gerrit and zuul currently? Or maybe it 
could be consider as a new feature to add? What do You think about it?

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com


__
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] CI meeting

[Slawomir Kaplonski]

Hi,

I have to cancel today’s Neutron CI meeting because of Public holidays in many 
countries. 
Next meeting will be on 8th May.

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com




__
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] Is there any way to recheck only one job?

[Slawomir Kaplonski]

Thanks for help.

> Wiadomość napisana przez Jens Harbott  w dniu 30.04.2018, 
> o godz. 10:41:
> 
> 2018-04-30 7:12 GMT+00:00 Slawomir Kaplonski :
>> Hi,
>> 
>> I wonder if there is any way to recheck only one type of job instead of 
>> rechecking everything.
>> For example sometimes I have to debug some random failure in specific job 
>> type, like „neutron-fullstack” and I want to collect some additional data or 
>> test something. So in such case I push some „Do not merge” patch and waits 
>> for job result - but I really don’t care about e.g. pep8 or UT results so 
>> would be good is I could run (recheck) only job which I want. That could 
>> safe some resources for other jobs and speed up my tests a little as I could 
>> be able to recheck only my job faster :)
>> 
>> Is there any way that I can do it with gerrit and zuul currently? Or maybe 
>> it could be consider as a new feature to add? What do You think about it?
> 
> This is intentionally not implemented as it could be used to trick
> patches leading to unstable behaviour into passing too easily, hiding
> possible issues.
> 
> As an alternative, you could include a change to .zuul.yaml into your
> test patch, removing all jobs except the one you are interested in.
> This would still run the jobs defined in project-config, but may be
> good enough for your scenario.

I did exactly that currently and it’s exactly what I expected. Thanks :)

> 
> __
> 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

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com
__
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] Is there any way to recheck only one job?

[Slawomir Kaplonski]

Hi,

> Wiadomość napisana przez Martin André  w dniu 03.05.2018, 
> o godz. 15:01:
> 
> On Mon, Apr 30, 2018 at 10:41 AM, Jens Harbott  wrote:
>> 2018-04-30 7:12 GMT+00:00 Slawomir Kaplonski :
>>> Hi,
>>> 
>>> I wonder if there is any way to recheck only one type of job instead of 
>>> rechecking everything.
>>> For example sometimes I have to debug some random failure in specific job 
>>> type, like „neutron-fullstack” and I want to collect some additional data 
>>> or test something. So in such case I push some „Do not merge” patch and 
>>> waits for job result - but I really don’t care about e.g. pep8 or UT 
>>> results so would be good is I could run (recheck) only job which I want. 
>>> That could safe some resources for other jobs and speed up my tests a 
>>> little as I could be able to recheck only my job faster :)
>>> 
>>> Is there any way that I can do it with gerrit and zuul currently? Or maybe 
>>> it could be consider as a new feature to add? What do You think about it?
>> 
>> This is intentionally not implemented as it could be used to trick
>> patches leading to unstable behaviour into passing too easily, hiding
>> possible issues.
> 
> Perhaps for these type of patches aimed at gathering data in CI, we
> could make it easier for developers to selectively trigger jobs while
> still retaining the "all voting jobs must pass in the same run" policy
> in place.
> 
> I'm thinking maybe a specially formatted line in the commit message
> could do the trick:
> 
>  Trigger-Job: neutron-fullstack

Yes, IMO it would be great to have something like that available :)

> 
> Even better if we can automatically put a Workflow -1 on the patches
> that contains a job triggering marker to prevent them from
> accidentally merging, and indicate to reviewers they can skip these
> patches.
> It's not uncommon to see such DNM patches, so I imagine we can save
> quite a lot of CI resource by implementing a system like that. And
> devs will be happier too because it can also be tricky at times to
> find what triggers a given job.

That was my initial though when I wrote email about it :)
Solution proposed by Jens is (almost) fine for me as it allows me to skip many 
tests but there is bunch of jobs defined in zuul directly (like 
openstack-tox-py27 or tempest-full) which are still running for my DNM patch.

> 
> Martin
> 
> __
> 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

— 
Best regards
Slawek Kaplonski
skapl...@redhat.com




__
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] Next Neutron CI meeting canceled

[Slawomir Kaplonski]

Hi,

As there is summit in next week, neutron CI meeting from 22.05 is cancelled. 
Next meeting will be normally on 29.05

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Next Neutron QoS meeting cancelled

[Slawomir Kaplonski]

Hi,

As there is summit in next week, neutron QoS meeting from 22.05 is cancelled. 
Next meeting will be normally on 05.06.2018

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Failing fullstack and ovsfw jobs

[Slawomir Kaplonski]

Hi,

Yesterday we had issue [1] with compiling openvswitch kernel module during 
fullstack and ovsfw scenario jobs.
This is now fixed by [2] so if You have a patch and those jobs are failing for 
You, please rebase it to have included this fix and it should works fine.

[1] https://bugs.launchpad.net/neutron/+bug/1772689
[2] https://review.openstack.org/#/c/570085/

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [tc][all] A culture change (nitpicking)

[Slawomir Kaplonski]

Hi,

> Wiadomość napisana przez Jay S Bryant  w dniu 
> 29.05.2018, o godz. 22:25:
> 
> 
> On 5/29/2018 3:19 PM, Doug Hellmann wrote:
>> Excerpts from Jonathan Proulx's message of 2018-05-29 16:05:06 -0400:
>>> On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote:
>>> :> >> maybe we're all saying the same thing here?
>>> :> > Yeah, I feel like we're all essentially in agreement that nits (of the
>>> :> > English mistake of typo type) do need to get fixed, but sometimes
>>> :> > (often?) putting the burden of fixing them on the original patch
>>> :> > contributor is neither fair nor constructive.
>>> :> I am ok with this statement if we are all in agreement that doing
>>> :> follow-up patches is an acceptable practice.
>>> :
>>> :Has it ever not been?
>>> :
>>> :It seems like it has always come down to a bit of negotiation with
>>> :the original author, hasn't it? And that won't change, except that
>>> :we will be emphasizing to reviewers that we encourage them to be
>>> :more active in seeking out that negotiation and then proposing
>>> :patches?
>>> 
>>> Exactly, it's more codifying a default.
>>> 
>>> It's not been unacceptable but I think there's some understandable
>>> reluctance to make changes to someone else's work, you don't want to
>>> seem like your taking over or getting in the way.  At least that's
>>> what's in my head when deciding should this be a comment or a patch.
>>> 
>>> I think this discussion suggests for certain class of "nits" patch is
>>> preferred to comment.  If that is true making this explicit is a good
>>> thing becuase let's face it my social skills are only marginally
>>> better than my speeling :)
>>> 
>>> -Jon
>>> 
>> OK, that's all good. I'm just surprised to learn that throwing a
>> follow-up patch on top of someone else's patch was ever seen as
>> discouraged.
>> 
>> The spice must flow,
>> Doug
> 
> Maybe it would be different now that I am a Core/PTL but in the past I had 
> been warned to be careful as it could be misinterpreted if I was changing 
> other people's patches or that it could look like I was trying to pad my 
> numbers. (I am a nit-picker though I do my best not to be.

Exactly. I remember when I was doing my first patch (or one of first patches) 
and someone pushed new PS with some very small nits fixed. I was a bit confused 
because of that and I was thinking why he did it instead of me?
Now it’s of course much more clear for me but for someone who is new 
contributor I think that this might be confusing. Maybe such person should at 
least remember to explain in comment why he pushed new PS and that’s not 
„stealing” work of original author :)

> 
> I am happy if people understand I am just trying to keep the process moving 
> and keep the read/flow of Cinder consistent.  :-)
> 
> Jay
> 
>> __
>> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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][stable] Stepping down from core

[Slawomir Kaplonski]

Hi Ihar,

Thanks for everything what You did for OpenStack and Neutron especially.
I remember that You were one of first people which I met in OpenStack community.
Thanks for all Your help then and during all time when we worked together :)

Good luck in Your new project :)

> Wiadomość napisana przez Ihar Hrachyshka  w dniu 
> 04.06.2018, o godz. 22:31:
> 
> Hi neutrinos and all,
> 
> As some of you've already noticed, the last several months I was
> scaling down my involvement in Neutron and, more generally, OpenStack.
> I am at a point where I feel confident my disappearance won't disturb
> the project, and so I am ready to make it official.
> 
> I am stepping down from all administrative roles I so far accumulated
> in Neutron and Stable teams. I shifted my focus to another project,
> and so I just removed myself from all relevant admin groups to reflect
> the change.
> 
> It was a nice 4.5 year ride for me. I am very happy with what we
> achieved in all these years and a bit sad to leave. The community is
> the most brilliant and compassionate and dedicated to openness group
> of people I was lucky to work with, and I am reminded daily how
> awesome it is.
> 
> I am far from leaving the industry, or networking, or the promise of
> open source infrastructure, so I am sure we will cross our paths once
> in a while with most of you. :) I also plan to hang out in our IRC
> channels and make snarky comments, be aware!
> 
> Thanks for the fish,
> Ihar
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [ovs] [neutron] openvswitch flows firewall driver

[Slawomir Kaplonski]

Hi,

I’m not sure about Queens but recently with [1] we switched default security 
group driver in devstack to „openvswitch”.
Since at least month we have scenario gate job with this SG driver running as 
voting and gating.
Currently, after switch devstack default driver to openvswitch it’s tested in 
many jobs in Neutron.

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

> Wiadomość napisana przez Tobias Urdin  w dniu 
> 11.06.2018, o godz. 05:20:
> 
> Hello everybody,
> I'm cross-posting this with operators list.
> 
> The openvswitch flows-based stateful firewall driver which uses the
> conntrack support in Linux kernel >= 4.3 (iirc) has been
> marked as experimental for several releases now, is there any
> information about flaws in this and why it should not be used in production?
> 
> It's still marked as experimental or missing documentation in the
> networking guide [1].
> 
> And to operators; is anybody running the OVS stateful firewall in
> production? (firewall_driver = openvswitch)
> 
> Appreciate any feedback :)
> Best regards
> 
> [1] https://docs.openstack.org/neutron/queens/admin/config-ovsfwdriver.html
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Neutron CI meeting 12.06.2018 cancelled

[Slawomir Kaplonski]

Hi,

I will be traveling tomorrow so I can’t chair CI meeting on 12.06.2018 so it is 
cancelled.
Next meeting will be normally at 19.06.2018.

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Question on the OVS configuration

[Slawomir Kaplonski]

Hi,

If You have vxlan network than traffic from it is going via vxlan tunnel which 
is in br-tun bridge instead of br-ex. 

> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 10:17:
> 
> Dear folks, 
>  
> I have setup a pretty simple OpenStack cluster in our lab based on devstack, 
> couples of guest VM are running on one controller node (this doesn’t looks 
> like a right behavior anyway),  the Neutron network is configured as OVS + 
> vxlan, the bridge “br-ex” configured as below:
>  
> Bridge br-ex
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port phy-br-ex
> Interface phy-br-ex
> type: patch
> options: {peer=int-br-ex}
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "2.8.0"
>  
>  
>  
> As you see, there is no external physical NIC bound to “br-ex”, so I guess 
> the traffic from the VM to external will use the default route set on the 
> controller node,  since there is a NIC (eno2) that can access external so I 
> bind it to “br-ex” like this: ovs-vsctl add-port br-ex eno2. now the “br-ex” 
> is configured as below:  
>  
> Bridge br-ex
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port phy-br-ex
> Interface phy-br-ex
> type: patch
> options: {peer=int-br-ex}
> *Port "eno2"*
> Interface "eno2"
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "2.8.0"
>  
>  
>  
> Looks like this is how it should be configured according to lots of wiki/blog 
> suggestion I have googled, but it doesn’t work as expected, ping from the VM, 
> the tcpdump shows the traffic still go the “eno1” which is the default route 
> on the controller node. 
>  
> Inside of VM
> ubuntu@test-br:~$ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=38 time=168 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=38 time=168 ms
> …
>  
> Dump the traffic on the “eno2”, got nothing
> $ sudo tcpdump -nn -i eno2 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eno2, link-type EN10MB (Ethernet), capture size 262144 bytes
> …
>  
> Dump the traffic on the “eno1” (internal NIC),  catch it!
> $ sudo tcpdump -nn -i eno1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 16:08:59.609888 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 
> 1, length 64
> 16:08:59.781042 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 1, 
> length 64
> 16:09:00.611453 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 
> 2, length 64
> 16:09:00.779550 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 2, 
> length 64
>  
>  
> $ sudo ip route
> default via 192.168.18.1 dev eno1  proto static  metric 100
> default via 192.168.8.1 dev eno2  proto static  metric 101
> 169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown
> 172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown
> 192.168.8.0/24 dev eno2  proto kernel  scope link  src 192.168.8.101  metric 
> 100
> 192.168.16.0/21 dev eno1  proto kernel  scope link  src 192.168.20.132  
> metric 100
> 192.168.42.0/24 dev br-ex  proto kernel  scope link  src 192.168.42.1
>  
>  
> What’s going wrong here? Do I miss something? Or some service need to be 
> restarted?
>  
> Anyone could help me out?  This question made me sick for many days!  Huge 
> thanks in the advance!
>  
>  
> Best Regards,
> Dave 
>  
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Question on the OVS configuration

[Slawomir Kaplonski]

Also, I think that You should sent such emails to openst...@lists.openstack.org 
or openstack-operat...@lists.openstack.org in the future :)

> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 10:17:
> 
> Dear folks, 
>  
> I have setup a pretty simple OpenStack cluster in our lab based on devstack, 
> couples of guest VM are running on one controller node (this doesn’t looks 
> like a right behavior anyway),  the Neutron network is configured as OVS + 
> vxlan, the bridge “br-ex” configured as below:
>  
> Bridge br-ex
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port phy-br-ex
> Interface phy-br-ex
> type: patch
> options: {peer=int-br-ex}
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "2.8.0"
>  
>  
>  
> As you see, there is no external physical NIC bound to “br-ex”, so I guess 
> the traffic from the VM to external will use the default route set on the 
> controller node,  since there is a NIC (eno2) that can access external so I 
> bind it to “br-ex” like this: ovs-vsctl add-port br-ex eno2. now the “br-ex” 
> is configured as below:  
>  
> Bridge br-ex
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port phy-br-ex
> Interface phy-br-ex
> type: patch
> options: {peer=int-br-ex}
> *Port "eno2"*
> Interface "eno2"
> Port br-ex
> Interface br-ex
> type: internal
> ovs_version: "2.8.0"
>  
>  
>  
> Looks like this is how it should be configured according to lots of wiki/blog 
> suggestion I have googled, but it doesn’t work as expected, ping from the VM, 
> the tcpdump shows the traffic still go the “eno1” which is the default route 
> on the controller node. 
>  
> Inside of VM
> ubuntu@test-br:~$ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=38 time=168 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=38 time=168 ms
> …
>  
> Dump the traffic on the “eno2”, got nothing
> $ sudo tcpdump -nn -i eno2 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eno2, link-type EN10MB (Ethernet), capture size 262144 bytes
> …
>  
> Dump the traffic on the “eno1” (internal NIC),  catch it!
> $ sudo tcpdump -nn -i eno1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 16:08:59.609888 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 
> 1, length 64
> 16:08:59.781042 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 1, 
> length 64
> 16:09:00.611453 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 
> 2, length 64
> 16:09:00.779550 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 2, 
> length 64
>  
>  
> $ sudo ip route
> default via 192.168.18.1 dev eno1  proto static  metric 100
> default via 192.168.8.1 dev eno2  proto static  metric 101
> 169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown
> 172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown
> 192.168.8.0/24 dev eno2  proto kernel  scope link  src 192.168.8.101  metric 
> 100
> 192.168.16.0/21 dev eno1  proto kernel  scope link  src 192.168.20.132  
> metric 100
> 192.168.42.0/24 dev br-ex  proto kernel  scope link  src 192.168.42.1
>  
>  
> What’s going wrong here? Do I miss something? Or some service need to be 
> restarted?
>  
> Anyone could help me out?  This question made me sick for many days!  Huge 
> thanks in the advance!
>  
>  
> Best Regards,
> Dave 
>  
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Question on the OVS configuration

[Slawomir Kaplonski]

Please send info about network to which You vm is connected and config of all 
bridges from ovs also.

> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 11:18:
> 
> Thanks Slawomir for your reply, so what's the right configuration if I want 
> my VM could be able to access external with physical NIC "eno2"?  Do I still 
> need add that NIC into "br-ex"?  
> 
> 
> Best Regards,
> Dave Chen
> 
> -Original Message-
> From: Slawomir Kaplonski [mailto:skapl...@redhat.com] 
> Sent: Friday, June 15, 2018 5:09 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Question on the OVS configuration
> 
> Hi,
> 
> If You have vxlan network than traffic from it is going via vxlan tunnel 
> which is in br-tun bridge instead of br-ex. 
> 
>> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 10:17:
>> 
>> Dear folks,
>> 
>> I have setup a pretty simple OpenStack cluster in our lab based on devstack, 
>> couples of guest VM are running on one controller node (this doesn’t looks 
>> like a right behavior anyway),  the Neutron network is configured as OVS + 
>> vxlan, the bridge “br-ex” configured as below:
>> 
>>Bridge br-ex
>>Controller "tcp:127.0.0.1:6633"
>>is_connected: true
>>fail_mode: secure
>>Port phy-br-ex
>>Interface phy-br-ex
>>type: patch
>>options: {peer=int-br-ex}
>>Port br-ex
>>Interface br-ex
>>type: internal
>> ovs_version: "2.8.0"
>> 
>> 
>> 
>> As you see, there is no external physical NIC bound to “br-ex”, so I guess 
>> the traffic from the VM to external will use the default route set on the 
>> controller node,  since there is a NIC (eno2) that can access external so I 
>> bind it to “br-ex” like this: ovs-vsctl add-port br-ex eno2. now the “br-ex” 
>> is configured as below:  
>> 
>>Bridge br-ex
>>Controller "tcp:127.0.0.1:6633"
>>is_connected: true
>>fail_mode: secure
>>Port phy-br-ex
>>Interface phy-br-ex
>>type: patch
>>options: {peer=int-br-ex}
>>*Port "eno2"*
>>Interface "eno2"
>>Port br-ex
>>Interface br-ex
>>type: internal
>>ovs_version: "2.8.0"
>> 
>> 
>> 
>> Looks like this is how it should be configured according to lots of 
>> wiki/blog suggestion I have googled, but it doesn’t work as expected, ping 
>> from the VM, the tcpdump shows the traffic still go the “eno1” which is the 
>> default route on the controller node. 
>> 
>> Inside of VM
>> ubuntu@test-br:~$ ping 8.8.8.8
>> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
>> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=38 time=168 ms
>> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=38 time=168 ms …
>> 
>> Dump the traffic on the “eno2”, got nothing $ sudo tcpdump -nn -i eno2 
>> icmp
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
>> decode listening on eno2, link-type EN10MB (Ethernet), capture size 
>> 262144 bytes …
>> 
>> Dump the traffic on the “eno1” (internal NIC),  catch it!
>> $ sudo tcpdump -nn -i eno1 icmp
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
>> decode listening on eno1, link-type EN10MB (Ethernet), capture size 
>> 262144 bytes
>> 16:08:59.609888 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 
>> 1439, seq 1, length 64
>> 16:08:59.781042 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, 
>> seq 1, length 64
>> 16:09:00.611453 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 
>> 1439, seq 2, length 64
>> 16:09:00.779550 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, 
>> seq 2, length 64
>> 
>> 
>> $ sudo ip route
>> default via 192.168.18.1 dev eno1  proto static  metric 100 default 
>> via 192.168.8.1 dev eno2  proto static  metric 101
>> 169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown
>> 172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 
>> linkdown
>> 192.168.8.0/24 dev eno2  proto kernel  scope link  src 192.168.8.101  
>> metric 100
>> 192.168.16.0/21 dev eno1  proto kernel  scope link  src 192.168.20.132  

Re: [openstack-dev] [neutron] Question on the OVS configuration

[Slawomir Kaplonski]

vs-vsctl show
> 0ee72d8a-65bc-4c82-884a-61b0e86b9893
>Manager "ptcp:6640:127.0.0.1"
>is_connected: true
>Bridge br-int
>Controller "tcp:127.0.0.1:6633"
>is_connected: true
>fail_mode: secure
>Port "qvo97604b93-55"
>tag: 1
>Interface "qvo97604b93-55"
>Port int-br-ex
>Interface int-br-ex
>type: patch
>options: {peer=phy-br-ex}
>Port "qr-c3f198ac-0b"
>tag: 1
>Interface "qr-c3f198ac-0b"
>type: internal
>Port "sg-8868b1a8-69"
>tag: 1
>Interface "sg-8868b1a8-69"
>type: internal
>Port br-int
>Interface br-int
>type: internal
>Port "qvo6f012656-74"
>tag: 1
>Interface "qvo6f012656-74"
>Port "fg-c4e5dcbc-a3"
>tag: 2
>Interface "fg-c4e5dcbc-a3"
>type: internal
>Port "tap10dc7b3e-a7"
>tag: 1
>Interface "tap10dc7b3e-a7"
>type: internal
>Port patch-tun
>Interface patch-tun
>type: patch
>options: {peer=patch-int}
>Port "qg-4014b9e8-ce"
>tag: 2
>Interface "qg-4014b9e8-ce"
>type: internal
>Port "qr-883cea95-31"
>tag: 1
>Interface "qr-883cea95-31"
>type: internal
>Port "sg-69c838e6-bb"
>tag: 1
>Interface "sg-69c838e6-bb"
>type: internal
>Bridge br-tun
>Controller "tcp:127.0.0.1:6633"
>is_connected: true
>fail_mode: secure
>Port "vxlan-c0a81218"
>Interface "vxlan-c0a81218"
>type: vxlan
>options: {df_default="true", in_key=flow, 
> local_ip="192.168.20.132", out_key=flow, remote_ip="192.168.18.24"}
>Port br-tun
>Interface br-tun
>type: internal
>Port patch-int
>Interface patch-int
>type: patch
>options: {peer=patch-tun}
>Bridge br-ex
>Controller "tcp:127.0.0.1:6633"
>is_connected: true
>fail_mode: secure
>Port phy-br-ex
>Interface phy-br-ex
>type: patch
>options: {peer=int-br-ex}
>Port "eno2"
>Interface "eno2"
>Port br-ex
>Interface br-ex
>type: internal
>ovs_version: "2.8.0"
> 
> 
> 
> Thanks!
> 
> Best Regards,
> Dave Chen
> 
> -Original Message-
> From: Slawomir Kaplonski [mailto:skapl...@redhat.com] 
> Sent: Friday, June 15, 2018 5:43 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Question on the OVS configuration
> 
> Please send info about network to which You vm is connected and config of all 
> bridges from ovs also.
> 
>> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 11:18:
>> 
>> Thanks Slawomir for your reply, so what's the right configuration if I want 
>> my VM could be able to access external with physical NIC "eno2"?  Do I still 
>> need add that NIC into "br-ex"?  
>> 
>> 
>> Best Regards,
>> Dave Chen
>> 
>> -Original Message-
>> From: Slawomir Kaplonski [mailto:skapl...@redhat.com]
>> Sent: Friday, June 15, 2018 5:09 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron] Question on the OVS 
>> configuration
>> 
>> Hi,
>> 
>> If You have vxlan network than traffic from it is going via vxlan tunnel 
>> which is in br-tun bridge instead of br-ex. 
>> 
>>> Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 
>>> 10:17:
>>> 
>>> Dear folks,
>>> 
>>> I have setup a pretty simple OpenStack cluster in our lab based on 
>>> devstack, couples of guest VM are running on one controller node (this 
>>> doesn’t looks like a right behavior anyway),  the Neutron network is 
>>> configured as OVS + vxlan, the bridge “br-ex” co

[openstack-dev] [neutron] bug deputy report

[Slawomir Kaplonski]

Hi,

Last week I was on bug deputy and I basically forgot about it. So I went 
through bugs from last week yesterday. Below is summary of those bugs:

Neutron-vpnaas bug:
* libreswan ipsec driver doesn't work with libreswan versions 3.23+ - 
https://bugs.launchpad.net/neutron/+bug/1776840 

CI related bugs:
* Critical bug for stable/queens 
https://bugs.launchpad.net/neutron/+bug/1777190 - should be fixed already,
* TestHAL3Agent.test_ha_router_restart_agents_no_packet_lost fullstack fails - 
https://bugs.launchpad.net/neutron/+bug/1776459 - I am checking logs for that, 
there are some patches related to it proposed but for now I don’t know exactly 
why this happens,
* neutron-rally job failing for stable/pike and stable/ocata - 
https://bugs.launchpad.net/neutron/+bug/1777506 - I am debugging why it happens 
like that,

DVR related bugs:
* DVR: Self recover from the loss of 'fg' ports in FIP Namespace - 
https://bugs.launchpad.net/neutron/+bug/1776984  - Swami is already working on 
it,
* DVR: FloatingIP create throws an error if the L3 agent is not running in the 
given host - https://bugs.launchpad.net/neutron/+bug/1776566 - Swami is already 
working on this one too,

DB related issues:
* Database connection was found disconnected; reconnecting: DBConnectionError - 
https://bugs.launchpad.net/neutron/+bug/1776896 - bug marker as Incomplete but 
IMO it should be closed as it doesn’t look like Neutron issue,

QoS issues:
* Inaccurate L3 QoS bandwidth - https://bugs.launchpad.net/neutron/+bug/1777598 
- reported today, fix already proposed

Docs bugs:
* [Doc] [FWaaS] Configuration of FWaaS v1 is confused - 
https://bugs.launchpad.net/neutron/+bug/1777547 - already in progress,

Already fixed issues reported this week:
* neutron-netns-cleanup explodes when trying to delete an OVS internal port - 
https://bugs.launchpad.net/neutron/+bug/1776469
* neutron-netns-cleanup does not configure privsep correctly - 
https://bugs.launchpad.net/neutron/+bug/1776468,
DVR scheduling checks wrong port binding profile for host in live-migration - 
https://bugs.launchpad.net/neutron/+bug/1776255

New RFE bugs:
* support vlan transparent in neutron network - 
https://bugs.launchpad.net/neutron/+bug/1777585 


— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] CI meeting 3.07.2018

[Slawomir Kaplonski]

Hi,

Next week I will not be able to lead CI meeting. As there is also holiday on 
4th July in US, I think that it would be good to cancel this meeting.
Next one will be as usually on 10.07 and Miguel Lavalle will be chair of it.
I’m coming back on 17.07

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [openstack-community] DevStack Installation issue

[Slawomir Kaplonski]

Hi,

In error log there is info that placement API service didn’t start properly. 
You should then go to placement API logs (/var/log/nova/ or 
/opt/stack/logs/nova probably) and check there what was wrong with it.

> Wiadomość napisana przez Abhijit Dutta  w dniu 
> 30.06.2018, o godz. 18:51:
> 
> Hi All,
> 
> Any help here will be appreciated.
> 
> ~Thanx
> Abhijit
> 
> From: Abhijit Dutta 
> Sent: Friday, June 29, 2018 8:10 AM
> To: Dr. Jens Harbott (frickler); OpenStack Development Mailing List (not for 
> usage questions)
> Subject: Re: [openstack-dev] [openstack-community] DevStack Installation issue
>  
> Hi,
> 
> As advised I installed Fedora 27 (Workstation) and tried with the latest 
> version of devstack (pulled from git).  However this time I got the following 
> error - 
> 
> ./stack.sh:1313:start_placement
> /opt/stack/devstack/lib/placement:184:start_placement_api
> /opt/stack/devstack/lib/placement:179:die
> [ERROR] /opt/stack/devstack/lib/placement:179 placement-api did not start
> Error on exit
> World dumping... see /opt/stack/logs/worlddump-2018-06-29-071219.txt for 
> details  (attached)
> 
> The local.cnf has been configured as:
> 
> [[local|localrc]]
> FLOATING_RANGE=192.168.1.224/27
> FIXED_RANGE=10.11.12.0/24
> FIXED_NETWORK_SIZE=256
> FLAT_INTERFACE=eth0
> ADMIN_PASSWORD=supersecret
> DATABASE_PASSWORD=iheartdatabases
> RABBIT_PASSWORD=flopsymopsy
> SERVICE_PASSWORD=iheartksl
> 
> I have configured a static IP which is 192.168.1.201 in my laptop, which has 
> dual core and 3gigs RAM.
> 
> Please let me know, what can cause this error.
> 
> ~Thanx
> Abhijit
> 
> 
> 
> 
> From: Dr. Jens Harbott (frickler) 
> Sent: Wednesday, June 27, 2018 3:53 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Abhijit Dutta
> Subject: Re: [openstack-dev] [openstack-community] DevStack Installation issue
>  
> 2018-06-27 16:58 GMT+02:00 Amy Marrich :
> > Abhijit,
> >
> > I'm forwarding your issue to the OpenStack-dev list so that the right people
> > might see your issue and respond.
> >
> > Thanks,
> >
> > Amy (spotz)
> >
> > -- Forwarded message --
> > From: Abhijit Dutta 
> > Date: Wed, Jun 27, 2018 at 5:23 AM
> > Subject: [openstack-community] DevStack Installation issue
> > To: "commun...@lists.openstack.org" 
> >
> >
> > Hi,
> >
> >
> > I am trying to install DevStack for the first time in a baremetal with
> > Fedora 28 installed.  While executing the stack.sh I am getting the
> > following error:
> >
> >
> > No match for argument: Django
> > Error: Unable to find a match
> >
> > Can anybody in the community help me out with this problem.
> 
> We are aware of some issues with deploying devstack on Fedora 28,
> these are being worked on, see
> https://review.openstack.org/#/q/status:open+project:openstack-dev/devstack+branch:master+topic:uwsgi-f28
> 
> If you want a quick solution, you could try deploying on Fedora 27 or
> Centos 7 instead.
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [nova][cinder][neutron][qa] Should we add a tempest-slow job?

[Slawomir Kaplonski]

Hi,

Thanks. I just send patch [1] to add this new job to Neutron failure rate 
Grafana dashboard.

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

> Wiadomość napisana przez Ghanshyam Mann  w dniu 
> 19.07.2018, o godz. 06:55:
> 
>> On Sun, May 13, 2018 at 1:20 PM, Ghanshyam Mann  
>> wrote: 
>>> On Fri, May 11, 2018 at 10:45 PM, Matt Riedemann  
>>> wrote: 
 The tempest-full job used to run API and scenario tests concurrently, and 
 if 
 you go back far enough I think it also ran slow tests. 
 
 Sometime in the last year or so, the full job was changed to run the 
 scenario tests in serial and exclude the slow tests altogether. So the API 
 tests run concurrently first, and then the scenario tests run in serial. 
 During that change, some other tests were identified as 'slow' and marked 
 as 
 such, meaning they don't get run in the normal tempest-full job. 
 
 There are some valuable scenario tests marked as slow, however, like the 
 only encrypted volume testing we have in tempest is marked slow so it 
 doesn't get run on every change for at least nova. 
>>> 
>>> Yes, basically slow tests were selected based on 
>>> https://ethercalc.openstack.org/nu56u2wrfb2b and there were frequent 
>>> gate failure for heavy tests mainly from ssh checks so we tried to 
>>> mark more tests as slow. 
>>> I agree that some of them are not really slow at least in today situation. 
>>> 
 
 There is only one job that can be run against nova changes which runs the 
 slow tests but it's in the experimental queue so people forget to run it. 
>>> 
>>> Tempest job 
>>> "legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend" 
>>> run those slow tests including migration and LVM  multibackend tests. 
>>> This job runs on tempest check pipeline and experimental (as you 
>>> mentioned) on nova and cinder [3]. We marked this as n-v to check its 
>>> stability and now it is good to go as voting on tempest. 
>>> 
 
 As a test, I've proposed a nova-slow job [1] which only runs the slow 
 tests 
 and only the compute API and scenario tests. Since there currently no 
 compute API tests marked as slow, it's really just running slow scenario 
 tests. Results show it runs 37 tests in about 37 minutes [2]. The overall 
 job runtime was 1 hour and 9 minutes, which is on average less than the 
 tempest-full job. The nova-slow job is also running scenarios that nova 
 patches don't actually care about, like the neutron IPv6 scenario tests. 
 
 My question is, should we make this a generic tempest-slow job which can 
 be 
 run either in the integrated-gate or at least in nova/neutron/cinder 
 consistently (I'm not sure if there are slow tests for just keystone or 
 glance)? I don't know if the other projects already have something like 
 this 
 that they gate on. If so, a nova-specific job for nova changes is fine for 
 me. 
>>> 
>>> +1 on idea. As of now slow marked tests are from nova, cinder and 
>>> neutron scenario tests and 2 API swift tests only [4]. I agree that 
>>> making a generic job in tempest is better for maintainability. We can 
>>> use existing job for that with below modification- 
>>> -  We can migrate 
>>> "legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend" job 
>>> zuulv3 in tempest repo 
>>> -  We can see if we can move migration tests out of it and use 
>>> "nova-live-migration" job (in tempest check pipeline ) which is much 
>>> better in live migration env setup and controlled by nova. 
>>> -  then it can be name something like 
>>> "tempest-scenario-multinode-lvm-multibackend". 
>>> -  run this job in nova, cinder, neutron check pipeline instead of 
>>> experimental. 
>> 
>> Like this - 
>> https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:scenario-tests-job
>>  
>> 
>> That makes scenario job as generic with running all scenario tests 
>> including slow tests with concurrency 2. I made few cleanup and moved 
>> live migration tests out of it which is being run by 
>> 'nova-live-migration' job. Last patch making this job as voting on 
>> tempest side. 
>> 
>> If looks good, we can use this to run on project side pipeline as voting. 
> 
> Update on this thread:
> Old Scenario  job 
> "legacy-tempest-dsvm-neutron-scenario-multinode-lvm-multibackend" has been 
> migrated to Tempest as new job named "tempest-scenario-all" job[1] 
> 
> Changes from old job to new job:
> - This new job will run all the scenario tests including slow with lvm 
> multibackend. Same as old job
> -  Executed the live migration API tests out of it. Live migration API tests 
> runs on separate  nova job "nova-live-migration".
> - This new job runs as voting on Tempest check and gate pipeline.
> 
> This is ready to use for cross project also. i have pushed the patch to nova, 
> neutron, cinder to use this new job[3] and remove 
> "legacy-tempest-dsvm

[openstack-dev] [Nova][Cinder][Tempest] Help with tempest.api.compute.servers.test_device_tagging.TaggedAttachmentsTest.test_tagged_attachment needed

[Slawomir Kaplonski]

Hi,

Since some time we see that test 
tempest.api.compute.servers.test_device_tagging.TaggedAttachmentsTest.test_tagged_attachment
 is failing sometimes.
Bug about that is reported for Tempest currently [1] but after small patch [2] 
was merged I was today able to check what cause this issue.

Test which is failing is in [3] and it looks that everything is going fine with 
it up to last line of test. So volume and port are created, attached, tags are 
set properly, both devices are detached properly also and at the end test is 
failing as in http://169.254.169.254/openstack/latest/meta_data.json still has 
some device inside.
And it looks now from [4] that it is volume which isn’t removed from this 
meta_data.json.
So I think that it would be good if people from Nova and Cinder teams could 
look at it and try to figure out what is going on there and how it can be fixed.

Thanks in advance for help.

[1] https://bugs.launchpad.net/tempest/+bug/1775947
[2] https://review.openstack.org/#/c/578765/
[3] 
https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_device_tagging.py#L330
[4] 
http://logs.openstack.org/69/567369/15/check/tempest-full/528bc75/job-output.txt.gz#_2018-07-19_10_06_09_273919

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [Nova][Cinder][Tempest] Help with tempest.api.compute.servers.test_device_tagging.TaggedAttachmentsTest.test_tagged_attachment needed

[Slawomir Kaplonski]

Hi,

Thx Artom for taking care of it. Did You made any progress?
I think that it might be quite important to fix as it failed around 50 times 
during last 7 days:
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22line%20386%2C%20in%20test_tagged_attachment%5C%22

> Wiadomość napisana przez Artom Lifshitz  w dniu 
> 19.07.2018, o godz. 19:28:
> 
> I've proposed [1] to add extra logging on the Nova side. Let's see if
> that helps us catch the root cause of this.
> 
> [1] https://review.openstack.org/584032
> 
> On Thu, Jul 19, 2018 at 12:50 PM, Artom Lifshitz  wrote:
>> Because we're waiting for the volume to become available before we
>> continue with the test [1], its tag still being present means Nova's
>> not cleaning up the device tags on volume detach. This is most likely
>> a bug. I'll look into it.
>> 
>> [1] 
>> https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_device_tagging.py#L378
>> 
>> On Thu, Jul 19, 2018 at 7:09 AM, Slawomir Kaplonski  
>> wrote:
>>> Hi,
>>> 
>>> Since some time we see that test 
>>> tempest.api.compute.servers.test_device_tagging.TaggedAttachmentsTest.test_tagged_attachment
>>>  is failing sometimes.
>>> Bug about that is reported for Tempest currently [1] but after small patch 
>>> [2] was merged I was today able to check what cause this issue.
>>> 
>>> Test which is failing is in [3] and it looks that everything is going fine 
>>> with it up to last line of test. So volume and port are created, attached, 
>>> tags are set properly, both devices are detached properly also and at the 
>>> end test is failing as in 
>>> http://169.254.169.254/openstack/latest/meta_data.json still has some 
>>> device inside.
>>> And it looks now from [4] that it is volume which isn’t removed from this 
>>> meta_data.json.
>>> So I think that it would be good if people from Nova and Cinder teams could 
>>> look at it and try to figure out what is going on there and how it can be 
>>> fixed.
>>> 
>>> Thanks in advance for help.
>>> 
>>> [1] https://bugs.launchpad.net/tempest/+bug/1775947
>>> [2] https://review.openstack.org/#/c/578765/
>>> [3] 
>>> https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_device_tagging.py#L330
>>> [4] 
>>> http://logs.openstack.org/69/567369/15/check/tempest-full/528bc75/job-output.txt.gz#_2018-07-19_10_06_09_273919
>>> 
>>> —
>>> Slawek Kaplonski
>>> Senior software engineer
>>> Red Hat
>>> 
>>> 
>>> __
>>> 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
>> 
>> 
>> 
>> --
>> --
>> Artom Lifshitz
>> Software Engineer, OpenStack Compute DFG
> 
> 
> 
> -- 
> --
> Artom Lifshitz
> Software Engineer, OpenStack Compute DFG
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [Nova][Cinder][Tempest] Help with tempest.api.compute.servers.test_device_tagging.TaggedAttachmentsTest.test_tagged_attachment needed

[Slawomir Kaplonski]

Thx :)

> Wiadomość napisana przez Matt Riedemann  w dniu 
> 26.07.2018, o godz. 18:32:
> 
> On 7/23/2018 4:20 AM, Slawomir Kaplonski wrote:
>> Thx Artom for taking care of it. Did You made any progress?
>> I think that it might be quite important to fix as it failed around 50 times 
>> during last 7 days:
>> http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22line%20386%2C%20in%20test_tagged_attachment%5C%22
> 
> I've proposed a Tempest change to skip that part of the test for now:
> 
> https://review.openstack.org/#/c/586292/
> 
> We could revert that and link it to artom's debug patch to see if we can 
> recreate with proper debug.
> 
> -- 
> 
> Thanks,
> 
> Matt
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [openstack-ansible] Change in our IRC channel

[Slawomir Kaplonski]

Maybe such change should be considered to be done globally on all OpenStack 
channels?

> Wiadomość napisana przez jean-phili...@evrard.me w dniu 01.08.2018, o godz. 
> 10:13:
> 
> Hello everyone,
> 
> Due to a continuously increasing spam [0] on our IRC channels, I have decided 
> to make our channel (#openstack-ansible on freenode) only joinable by 
> Freenode's nickserv registered users.
> 
> I am sorry for the inconvenience, as it will now be harder to reach us (but 
> it's not that hard to register! [1]). The conversations will be easier to 
> follow though.
> 
> You can still contact us on the mailing lists too.
> 
> Regards,
> Jean-Philippe Evrard (evrardjp)
> 
> [0]: https://freenode.net/news/spambot-attack
> [1]: https://freenode.net/kb/answer/registration
> 
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [sdk] Propose adding Dmitry Tantsur to openstacksdk-core

[Slawomir Kaplonski]

+1

> Wiadomość napisana przez Monty Taylor  w dniu 
> 10.08.2018, o godz. 14:06:
> 
> Hey everybody,
> 
> I'd like to propose Dmitry Tantsur (dtantsur) as a new openstacksdk core team 
> member. He's been diving in to some of the hard bits, such as dealing with 
> microversions, and has a good grasp of the resource/proxy layer. His reviews 
> have been super useful broadly, and he's also helping drive Ironic related 
> functionality.
> 
> Thoughts/concerns?
> 
> Thanks!
> Monty
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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 team meeting cancelled

[Slawomir Kaplonski]

Hi,

As Miguel is not available this week, Tuesday’s Neutron team meeting is 
cancelled.
Next meeting should be normally on Monday, 20.08

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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 CI meeting on 14.08 cancelled

[Slawomir Kaplonski]

Hi,

As few of Neutron core reviewers are not available this week, Tuesday’s CI 
meeting on 14.08 is cancelled.
Next meeting will be at 21.08.2018

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Broken pep8 job

[Slawomir Kaplonski]

Hi,

It looks that pep8 job in Neutron is currently broken because of new version of 
bandit (1.5.0).
If You have in Your patch failure of pep8 job with error like [1] please don’t 
recheck as it will not help.
I did some patch which should fix it [2]. Will let You know when it will be 
fixed and You will be able to rebase You patches.

[1] 
http://logs.openstack.org/37/382037/67/check/openstack-tox-pep8/e2bbd84/job-output.txt.gz#_2018-08-16_21_45_55_366148
[2] https://review.openstack.org/#/c/592884/

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Broken pep8 job

[Slawomir Kaplonski]

Thx,

I just did similar patches for stable/rocky [1] and stable/queens [2] in 
Neutron repo:

[1] https://review.openstack.org/#/c/593075/
[2] https://review.openstack.org/#/c/593078/


> Wiadomość napisana przez Doug Hellmann  w dniu 
> 17.08.2018, o godz. 16:34:
> 
> Excerpts from Slawomir Kaplonski's message of 2018-08-17 10:16:35 +0200:
>> Hi,
>> 
>> It looks that pep8 job in Neutron is currently broken because of new version 
>> of bandit (1.5.0).
>> If You have in Your patch failure of pep8 job with error like [1] please 
>> don’t recheck as it will not help.
>> I did some patch which should fix it [2]. Will let You know when it will be 
>> fixed and You will be able to rebase You patches.
>> 
>> [1] 
>> http://logs.openstack.org/37/382037/67/check/openstack-tox-pep8/e2bbd84/job-output.txt.gz#_2018-08-16_21_45_55_366148
>> [2] https://review.openstack.org/#/c/592884/
>> 
>> — 
>> Slawek Kaplonski
>> Senior software engineer
>> Red Hat
>> 
> 
> We had this problem in oslo.concurrency, too.
> 
> Because bandit is considered to be a linter and different teams may
> want to use different versions, it is not managed through the
> constraints list (there is no co-installability requirement for
> linters). Some of the projects using it do not have it capped, so
> new releases that introduce breaking changes like this can cause
> gate issues.
> 
> In the oslo.concurrency stable branch we capped the version of
> bandit to avoid having to backport changes just to fix the linter
> errors. We made code changes in master to address them and left
> bandit uncapped there, for now.
> 
> Doug
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Broken pep8 job

[Slawomir Kaplonski]

Hi,

Patch [1] is merged now so You can rebase Your patches for master branch and 
pep8 should be fine now.

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

> Wiadomość napisana przez Slawomir Kaplonski  w dniu 
> 17.08.2018, o godz. 10:16:
> 
> Hi,
> 
> It looks that pep8 job in Neutron is currently broken because of new version 
> of bandit (1.5.0).
> If You have in Your patch failure of pep8 job with error like [1] please 
> don’t recheck as it will not help.
> I did some patch which should fix it [2]. Will let You know when it will be 
> fixed and You will be able to rebase You patches.
> 
> [1] 
> http://logs.openstack.org/37/382037/67/check/openstack-tox-pep8/e2bbd84/job-output.txt.gz#_2018-08-16_21_45_55_366148
> [2] https://review.openstack.org/#/c/592884/
> 
> — 
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Old patches cleaning

[Slawomir Kaplonski]

Hi,

In Neutron we have many patches without any activity since long time. To make 
list of patches a bit smaller I want to run script [1] soon.
I will run it only for projects like:
* neutron
* neutron-lib
* neutron-tempest-plugin

But if You want to run it for Your stadium project it should be also possible 
after my patch [2] will be merged.
If You have any concerns about running this script, please raise Your hand now 
:)

If You are owner of patch which will be abandoned and You will want to continue 
work on it, You can always restore Your patch and continue work on it then.

[1] 
https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh
[2] https://review.openstack.org/#/c/594326

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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][api][grapql] Proof of Concept

[Slawomir Kaplonski]

Hi Miguel,

I’m not sure but maybe You were looking for those patches:

https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/graphql


> Wiadomość napisana przez Miguel Lavalle  w dniu 
> 23.08.2018, o godz. 18:57:
> 
> Hi Gilles,
> 
> Ed pinged me earlier today in IRC in regards to this topic. After reading 
> your message, I assumed that you had patches up for review in Gerrit. I 
> looked for them, with the intent to list them in the agenda of the next 
> Neutron team meeting, to draw attention to them. I couldn't find any, though: 
> https://review.openstack.org/#/q/owner:%22Gilles+Dubreuil+%253Cgdubreui%2540redhat.com%253E%22
> 
> So, how can we help? This is our meetings schedule: 
> http://eavesdrop.openstack.org/#Neutron_Team_Meeting. Given that you are Down 
> Under at UTC+10, the most convenient meeting for you is the one on Monday 
> (even weeks), which would be Tuesday at 7am for you. Please note that we have 
> an on demand section in our agenda: 
> https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda. Feel free 
> to add topics in that section when you have something to discuss with the 
> Neutron team.
> 
> Best regards
> 
> Miguel
> 
> On Sun, Aug 19, 2018 at 10:57 PM, Gilles Dubreuil  wrote:
> 
> 
> On 25/07/18 23:48, Ed Leafe wrote:
> On Jun 6, 2018, at 7:35 PM, Gilles Dubreuil  wrote:
> The branch is now available under feature/graphql on the neutron core 
> repository [1].
> I wanted to follow up with you on this effort. I haven’t seen any activity on 
> StoryBoard for several weeks now, and wanted to be sure that there was 
> nothing blocking you that we could help with.
> 
> 
> -- Ed Leafe
> 
> 
> 
> Hi Ed,
> 
> Thanks for following up.
> 
> There has been 2 essential counterproductive factors to the effort.
> 
> The first is that I've been busy attending issues on other part of my job.
> The second one is the lack of response/follow-up from the Neutron core team.
> 
> We have all the plumbing in place but we need to layer the data through oslo 
> policies.
> 
> Cheers,
> Gilles
> 
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Appointing Slawek Kaplonski to the Neutron Drivers team

[Slawomir Kaplonski]

Hi,

Thanks a lot. I will do my best to help Neutron Drivers team :)

> Wiadomość napisana przez Assaf Muller  w dniu 27.08.2018, o 
> godz. 19:18:
> 
> On Mon, Aug 27, 2018 at 12:42 PM, Miguel Lavalle  wrote:
>> Dear Neutron team,
>> 
>> In order to help the Neutron Drivers team to perform its very important job
>> of guiding the community to evolve the OpenStack Networking architecture to
>> meet the needs of our current and future users [1], I have asked Slawek
>> Kaplonski to join it. Over the past few years, he has gained very valuable
>> experience with OpenStack Networking, both as a deployer  and more recently
>> working with one of our key packagers. He played a paramount role in
>> implementing our QoS (Quality of Service) features, currently leading that
>> sub-team. He also leads the CI sub-team, making sure the prompt discovery
>> and fixing of bugs in our software. On top of that, he is one of our most
>> active reviewers, contributor of code to our reference implementation and
>> fixer of bugs. I am very confident in Slawek making great contributions to
>> the Neutron Drivers team.
> 
> Congratulations Slawek, I think you'll do a great job :)
> 
>> 
>> Best regards
>> 
>> Miguel
>> 
>> [1]
>> https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams.html#drivers-team
>> 
>> __
>> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Stepping down from Neutron core team

[Slawomir Kaplonski]

It’s sad news. Thanks Kuba for all Your help You gave me when I was newcomer in 
Neutron community.
Good luck in Your next projects :)

> Wiadomość napisana przez Jakub Libosvar  w dniu 
> 31.08.2018, o godz. 10:24:
> 
> Hi all,
> 
> as you have might already heard, I'm no longer involved in Neutron
> development due to some changes. Therefore I'm officially stepping down
> from the core team because I can't provide same quality reviews as I
> tried to do before.
> 
> I'd like to thank you all for the opportunity I was given in the Neutron
> team, thank you for all I have learned over the years professionally,
> technically and personally. Tomorrow it's gonna be exactly 5 years since
> I started hacking Neutron and I must say I really enjoyed working with
> all Neutrinos here and I had privilege to meet most of you in person and
> that has an extreme value for me. Keep on being a great community!
> 
> Thank you again!
> Kuba
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [octavia] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Slawomir Kaplonski]

Congratulation Carlos :)

> Wiadomość napisana przez Carlos Goncalves  w dniu 
> 31.08.2018, o godz. 20:36:
> 
> Thanks for the trust and opportunity, folks!
> 
> On Fri, Aug 31, 2018 at 7:59 PM, Michael Johnson  wrote:
> With a unanimous vote I would like to welcome Carlos to the Octavia Core team!
> 
> Michael
> 
> 
> On Fri, Aug 31, 2018 at 10:42 AM Adam Harwell  wrote:
> >
> > +1 for sure!
> >
> > On Sat, Sep 1, 2018, 01:41 Carlos Goncalves  wrote:
> >>
> >> Ha! Gracias for the kind words, Miguel! :-)
> >>
> >> On Fri, Aug 31, 2018 at 5:55 PM, Miguel Lavalle  
> >> wrote:
> >>>
> >>> Well, I don't vote here but I stiil want to express my +1. I knew this 
> >>> was going to happen sooner rather than later
> >>>
> >>> On Thu, Aug 30, 2018 at 10:24 PM, Michael Johnson  
> >>> wrote:
> 
>  Hello Octavia community,
> 
>  I would like to propose Carlos Goncalves as a core reviewer on the
>  Octavia project.
> 
>  Carlos has provided numerous enhancements to the Octavia project,
>  including setting up the grenade gate for Octavia upgrade testing.
> 
>  Over the last few releases he has also been providing quality reviews,
>  in line with the other core reviewers [1]. I feel that Carlos would
>  make an excellent addition to the Octavia core reviewer team.
> 
>  Existing Octavia core reviewers, please reply to this email with your
>  support or concerns with adding Jacky to the core team.
> 
>  Michael
> 
>  [1] http://stackalytics.com/report/contribution/octavia-group/90
> 
>  __
>  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
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] No Neutron QoS meeting on Tuesday 11.09

[Slawomir Kaplonski]

Hi,

Due to PTG in Denver QoS meeting on Tuesday 11.09 is cancelled.
Next one will be at 25.09

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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 CI meeting on Tuesday 11.09

[Slawomir Kaplonski]

Hi,

Due to PTG in Denver CI meeting on Tuesday 11.09 is cancelled.
Next one will be at 18.09

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Pep8 job failures

[Slawomir Kaplonski]

Hi,

Recently bump of eventlet to 0.24.0 was merged in requirements repo [1]. 
That caused issue in Neutron and pep8 job is now failing. See [2]. So if You 
have pep8 failed in Your patch with error like in [3] please don’t recheck job 
- it will not help :)
Patch to fix that is already proposed [4]. When it will be merged, please 
rebase Your patch and this issue should be solved.

[1] https://review.openstack.org/#/c/589382/
[2] https://bugs.launchpad.net/neutron/+bug/1791178
[3] 
http://logs.openstack.org/37/382037/73/gate/openstack-tox-pep8/7f200e6/job-output.txt.gz#_2018-09-06_17_48_34_700485
[4] https://review.openstack.org/600565

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Pep8 job failures

[Slawomir Kaplonski]

Hi,

As patch [1] is finally merged You can now rebase Your neutron patches and pep8 
tests should be good.

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

> Wiadomość napisana przez Slawomir Kaplonski  w dniu 
> 07.09.2018, o godz. 01:30:
> 
> Hi,
> 
> Recently bump of eventlet to 0.24.0 was merged in requirements repo [1]. 
> That caused issue in Neutron and pep8 job is now failing. See [2]. So if You 
> have pep8 failed in Your patch with error like in [3] please don’t recheck 
> job - it will not help :)
> Patch to fix that is already proposed [4]. When it will be merged, please 
> rebase Your patch and this issue should be solved.
> 
> [1] https://review.openstack.org/#/c/589382/
> [2] https://bugs.launchpad.net/neutron/+bug/1791178
> [3] 
> http://logs.openstack.org/37/382037/73/gate/openstack-tox-pep8/7f200e6/job-output.txt.gz#_2018-09-06_17_48_34_700485
> [4] https://review.openstack.org/600565
> 
> — 
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Removing external_bridge_name config option

[Slawomir Kaplonski]

Hi,

Some time ago I proposed patch [1] to remove config option 
„external_network_bridge”.
This option was deprecated to removal in Ocata so I think it’s time to get rid 
of it finally.

There is quite many projects which still uses this option [2]. I will try to 
propose patches for those projects to remove it also from there but if You are 
maintainer of such project, it would be great if You can remove it. If You 
would do it, please use same topic as is in [1] - it will allow me easier track 
which projects already removed it.
Thx a lot in advance for any help :)

[1] https://review.openstack.org/#/c/567369
[2] 
http://codesearch.openstack.org/?q=external_network_bridge&i=nope&files=&repos=

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Core status

[Slawomir Kaplonski]

Hi,

Thanks for all Your work for Neutron and good luck in Your new role :)

> Wiadomość napisana przez Gary Kotton  w dniu 19.09.2018, 
> o godz. 20:19:
> 
> Hi,
> I have recently transitioned to a new role where I will be working on other 
> parts of OpenStack. Sadly I do not have the necessary cycles to maintain my 
> core responsibilities in the neutron community. Nonetheless I will continue 
> to be involved.
> Thanks
> Gary
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Ryu integration with Openstack

[Slawomir Kaplonski]

Hi,

> Wiadomość napisana przez Niket Agrawal  w dniu 
> 26.09.2018, o godz. 18:11:
> 
> Hello,
> 
> I have a question regarding the Ryu integration in Openstack. By default, the 
> openvswitch bridges (br-int, br-tun and br-ex) are registered to a controller 
> running on 127.0.0.1 and port 6633. The output of ovs-vsctl get-manager is 
> ptcp:127.0.0.1:6640. This is noticed on the nova compute node. However there 
> is a different instance of the same Ryu controller running on the neutron 
> gateway as well and the three openvswitch bridges (br-int, br-tun and br-ex) 
> are registered to this instance of Ryu controller. If I stop 
> neutron-openvswitch agent on the nova compute node, the bridges there are no 
> longer connected to the controller, but the bridges in the neutron gateway 
> continue to remain connected to the controller. Only when I stop the neutron 
> openvswitch agent in the neutron gateway as well, the bridges there get 
> disconnected. 
> 
> I'm unable to find where in the Openstack code I can access this 
> implementation, because I intend to make a few tweaks to this architecture 
> which is present currently. Also, I'd like to know which app is the Ryu SDN 
> controller running by default at the moment. I feel the information in the 
> code can help me find it too.

Ryu app is started by neutron-openvswitch-agent in: 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/main.py#L34
Is it what You are looking for?

> 
> Regards,
> Niket
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Ryu integration with Openstack

[Slawomir Kaplonski]

Hi,

Code of app is in 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/ovs_ryuapp.py
 and classes for specific bridge types are in 
https://github.com/openstack/neutron/tree/master/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native

> Wiadomość napisana przez Niket Agrawal  w dniu 
> 27.09.2018, o godz. 00:08:
> 
> Hi,
> 
> Thanks for your reply. Is there a way to access the code that is running in 
> the app to see what is the logic implemented in the app?
> 
> Regards,
> Niket
> 
> On Wed, Sep 26, 2018 at 10:31 PM Slawomir Kaplonski  
> wrote:
> Hi,
> 
> > Wiadomość napisana przez Niket Agrawal  w dniu 
> > 26.09.2018, o godz. 18:11:
> > 
> > Hello,
> > 
> > I have a question regarding the Ryu integration in Openstack. By default, 
> > the openvswitch bridges (br-int, br-tun and br-ex) are registered to a 
> > controller running on 127.0.0.1 and port 6633. The output of ovs-vsctl 
> > get-manager is ptcp:127.0.0.1:6640. This is noticed on the nova compute 
> > node. However there is a different instance of the same Ryu controller 
> > running on the neutron gateway as well and the three openvswitch bridges 
> > (br-int, br-tun and br-ex) are registered to this instance of Ryu 
> > controller. If I stop neutron-openvswitch agent on the nova compute node, 
> > the bridges there are no longer connected to the controller, but the 
> > bridges in the neutron gateway continue to remain connected to the 
> > controller. Only when I stop the neutron openvswitch agent in the neutron 
> > gateway as well, the bridges there get disconnected. 
> > 
> > I'm unable to find where in the Openstack code I can access this 
> > implementation, because I intend to make a few tweaks to this architecture 
> > which is present currently. Also, I'd like to know which app is the Ryu SDN 
> > controller running by default at the moment. I feel the information in the 
> > code can help me find it too.
> 
> Ryu app is started by neutron-openvswitch-agent in: 
> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/main.py#L34
> Is it what You are looking for?
> 
> > 
> > Regards,
> > Niket
> > __
> > 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
> 
> — 
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [goals][upgrade-checkers] Oslo library status

[Slawomir Kaplonski]

Hi,

I start working on „neutron-status upgrade check” tool with noop operation for 
now. Patch is in [1]
I started using this new oslo_upgradecheck library in version 0.0.1.dev15 which 
is available on pypi.org but I see that in master there are some changes 
already (like shorted names of base classes).
So my question here is: should I just wait a bit more for kind of „stable” 
version of this lib and then push neutron patch to review (do You have any eta 
for that?), or maybe we shouldn’t rely on this oslo library in this release and 
implement all on our own, like it is done currently in nova?

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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [goals][upgrade-checkers] Oslo library status

[Slawomir Kaplonski]

Ok. Thx for info Matt. My patch is now marked as WIP and I will wait for 
release of this lib then.

> Wiadomość napisana przez Matt Riedemann  w dniu 
> 08.10.2018, o godz. 18:08:
> 
> On 10/7/2018 4:10 AM, Slawomir Kaplonski wrote:
>> I start working on „neutron-status upgrade check” tool with noop operation 
>> for now. Patch is in [1]
>> I started using this new oslo_upgradecheck library in version 0.0.1.dev15 
>> which is available on pypi.org but I see that in master there are some 
>> changes already (like shorted names of base classes).
>> So my question here is: should I just wait a bit more for kind of „stable” 
>> version of this lib and then push neutron patch to review (do You have any 
>> eta for that?), or maybe we shouldn’t rely on this oslo library in this 
>> release and implement all on our own, like it is done currently in nova?
>> [1]https://review.openstack.org/#/c/608444/
> 
> I would wait. I think there are just a couple of changes we need to get into 
> the library (one of which changes the interface) and then we can do a 
> release. Sean McGinnis is waiting on the release for Cinder as well.
> 
> -- 
> 
> Thanks,
> 
> Matt
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Bug deputy report - week 42

[Slawomir Kaplonski]

Hi,

I was on bug deputy in week of 8.10.2018 to 15.10.2018.
Below is summary of reported bugs for Neutron:


Bugs which needs some look to confirm them:
* https://bugs.launchpad.net/neutron/+bug/1795432 - neutron does not create the 
necessary iptables rules for dhcp agents when linuxbridge is used
This one should be confirmed on multinode environment with Linuxbridge, 
I didn’t have such env to work on that.

* https://bugs.launchpad.net/neutron/+bug/1797368 - Trunk: different behavior 
of admin_state_up attribute between trunk and port
I have no experience with trunks and I would like someone else to take 
a look on that. From description it looks for me that it’s valid issue

* https://bugs.launchpad.net/neutron/+bug/1795816 - neutron_dynamic_routing Bgp 
floatingip_update KeyError: 'last_known_router_id
Should be good that someone more familiar with neutron-dynamic-routing 
could take a look on it.
I don’t have environment to confirm it but from bug report it looks as 
valid bug.
Importance set to medium


Bugs triaged or triage in progress already:
* https://bugs.launchpad.net/neutron/+bug/1796491 - DVR Floating IP setup in 
the SNAT namespace of the network node and also in the qrouter namespace in the 
compute node 
Swami is checking if it wasn’t already fixed…

* https://bugs.launchpad.net/neutron/+bug/1796824 - Port in some type of 
device_owner should not allow update IP address
Importance set to Medium

* https://bugs.launchpad.net/neutron/+bug/1797037 - Extra routes configured on 
routers are not set in the router namespace and snat namespace with DVR-HA 
routers
already in progress, importance Medium

* https://bugs.launchpad.net/neutron/+bug/1796854 - Neutron doesn't respect 
advscv role while creating port
Importance set to Medium, this is an neutron-lib issue

* https://bugs.launchpad.net/neutron/+bug/1796976 - neutron.conf needs 
lock_path set for router to operate 
Docs issue - importance Low,

* https://bugs.launchpad.net/neutron/+bug/1797084 - Stale namespaces when 
fallback tunnels are present
Importance Low, patch already proposed by dalvarez

* https://bugs.launchpad.net/neutron/+bug/1797298 - Router gateway device are 
repeatedly configured When ha changed
Importance Low, patch already proposed

* https://bugs.launchpad.net/neutron/+bug/1796703 - HA router interfaces in 
standby state 
Needs look by some L3 experts - I already raised this on on L3 Sub-team 
meeting and Brian is triaging it now

* https://bugs.launchpad.net/neutron/+bug/1796230 - no libnetfilter-log1 
package on centos 
Waiting for reply for Brian’s question now….

* https://bugs.launchpad.net/neutron/+bug/1763608 - Netplan ignores Interfaces 
without IP Addresses 
I asked how it’s related to neutron as I don’t understand that. Waiting 
for reply now.

* https://bugs.launchpad.net/neutron/+bug/1795222 - [l3] router agent side 
gateway IP not changed if directly change IP address
Importance medium, patch already proposed

* https://bugs.launchpad.net/neutron/+bug/1797663 - refactor def 
_get_dvr_sync_data from neutron/db/l3_dvr_db.py
Importance wishlist,

* https://bugs.launchpad.net/neutron/+bug/1796629 - Incorrectly passing ext_ips 
as gw_ips after creating router gateway
Importance set to medium


RFEs:
* https://bugs.launchpad.net/neutron/+bug/1796925 - [RFE] port forwarding 
floating IP QoS
* https://bugs.launchpad.net/neutron/+bug/1797140 - [RFE] create port by 
providing parameters subnet_id only

Potential RFEs maybe:
* https://bugs.launchpad.net/neutron/+bug/1792890 - The user can delete a 
security group which is used as remote-group-id
It looks like maybe potential RFE as it may change current API behavior


— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [Openstack-sigs] [all] Naming the T release of OpenStack

[Slawomir Kaplonski]

> Wiadomość napisana przez Remo Mattei  w dniu 18.10.2018, o godz. 
> 19:08:
> 
> Michal, that will never work it’s 11 characters long

Shorter could be Openstack Trouble ;)
> 
> 
>  
> 
>> On Oct 18, 2018, at 09:43, Eric Fried  wrote:
>> 
>> Sorry, I'm opposed to this idea.
>> 
>> I admit I don't understand the political framework, nor have I read the
>> governing documents beyond [1], but that document makes it clear that
>> this is supposed to be a community-wide vote.  Is it really legal for
>> the TC (or whoever has merge rights on [2]) to merge a patch that gives
>> that same body the power to take the decision out of the hands of the
>> community? So it's really an oligarchy that gives its constituency the
>> illusion of democracy until something comes up that it feels like not
>> having a vote on? The fact that it's something relatively "unimportant"
>> (this time) is not a comfort.
>> 
>> Not that I think the TC would necessarily move forward with [2] in the
>> face of substantial opposition from non-TC "cores" or whatever.
>> 
>> I will vote enthusiastically for "Train". But a vote it should be.
>> 
>> -efried
>> 
>> [1] https://governance.openstack.org/tc/reference/release-naming.html
>> [2] https://review.openstack.org/#/c/611511/
>> 
>> On 10/18/2018 10:52 AM, arkady.kanev...@dell.com wrote:
>>> +1 for the poll.
>>> 
>>> Let’s follow well established process.
>>> 
>>> If we want to add Train as one of the options for the name I am OK with it.
>>> 
>>>  
>>> 
>>> *From:* Jonathan Mills 
>>> *Sent:* Thursday, October 18, 2018 10:49 AM
>>> *To:* openstack-s...@lists.openstack.org
>>> *Subject:* Re: [Openstack-sigs] [all] Naming the T release of OpenStack
>>> 
>>>  
>>> 
>>> [EXTERNAL EMAIL]
>>> Please report any suspicious attachments, links, or requests for
>>> sensitive information.
>>> 
>>> +1 for just having a poll
>>> 
>>>  
>>> 
>>> On Thu, Oct 18, 2018 at 11:39 AM David Medberry >> > wrote:
>>> 
>>>I'm fine with Train but I'm also fine with just adding it to the
>>>list and voting on it. It will win.
>>> 
>>> 
>>> 
>>>Also, for those not familiar with the debian/ubuntu command "sl",
>>>now is the time to become so.
>>> 
>>> 
>>> 
>>>apt install sl
>>> 
>>>sl -Flea #ftw
>>> 
>>> 
>>> 
>>>On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds
>>>mailto:t...@bakeyournoodle.com>> wrote:
>>> 
>>>Hello all,
>>>As per [1] the nomination period for names for the T release
>>>have
>>>now closed (actually 3 days ago sorry).  The nominated names and any
>>>qualifying remarks can be seen at2].
>>> 
>>>Proposed Names
>>> * Tarryall
>>> * Teakettle
>>> * Teller
>>> * Telluride
>>> * Thomas
>>> * Thornton
>>> * Tiger
>>> * Tincup
>>> * Timnath
>>> * Timber
>>> * Tiny Town
>>> * Torreys
>>> * Trail
>>> * Trinidad
>>> * Treasure
>>> * Troublesome
>>> * Trussville
>>> * Turret
>>> * Tyrone
>>> 
>>>Proposed Names that do not meet the criteria
>>> * Train
>>> 
>>>However I'd like to suggest we skip the CIVS poll and select
>>>'Train' as
>>>the release name by TC resolution[3].  My think for this is
>>> 
>>> * It's fun and celebrates a humorous moment in our community
>>> * As a developer I've heard the T release called Train for quite
>>>   sometime, and was used often at the PTG[4].
>>> * As the *next* PTG is also in Colorado we can still choose a
>>>   geographic based name for U[5]
>>> * If train causes a problem for trademark reasons then we can
>>>always
>>>   run the poll
>>> 
>>>I'll leave[3] for marked -W for a week for discussion to happen
>>>before the
>>>TC can consider / vote on it.
>>> 
>>>Yours Tony.
>>> 
>>>[1]
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html
>>>[2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals
>>>[3]
>>>
>>> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53
>>>[4] https://twitter.com/vkmc/status/1040321043959754752
>>>[5]
>>>https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z
>>>
>>> 
>>>___
>>>openstack-sigs mailing list
>>>openstack-s...@lists.openstack.org
>>>
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>>> 
>>>___
>>>openstack-sigs mailing list
>>>openstack-s...@lists.openstack.org
>>>
>>>http:/

Re: [openstack-dev] Neutron stadium project Tempest plugins

[Slawomir Kaplonski]

Hi,

Thx Miguel for raising this.
List of tempest plugins is on 
https://docs.openstack.org/tempest/latest/plugin-registry.html - if URL for 
Your plugin is the same as Your main repo, You should move Your tempest plugin 
code.


> Wiadomość napisana przez Miguel Lavalle  w dniu 
> 23.10.2018, o godz. 16:59:
> 
> Dear Neutron Stadium projects,
> 
> In a QA session during the recent PTG in Denver, it was suggested that the 
> Stadium projects should move their Tempest plugins to a repository of their 
> own or added to the Neutron Tempest plugin repository 
> (https://github.com/openstack/neutron-tempest-plugin). The purpose of this 
> message is to start a conversation for the Stadium projects to indicate what 
> is their preference. Please respond to this thread indicating how do you want 
> to move forward.
> 
> Best regards
> 
> Miguel
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)

[Slawomir Kaplonski]

Hi,

> Wiadomość napisana przez Jeremy Stanley  w dniu 
> 06.11.2018, o godz. 22:25:
> 
> On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote:
> [...]
>> also add jobs like "devstack-xenial" and "tempest-full-xenial"
>> which projects can use still for some time if their job on Bionic
>> would be broken now?
> [...]
> 
> That opens the door to piecemeal migration, which (as we similarly
> saw during the Trusty to Xenial switch) will inevitably lead to
> projects who no longer gate on Xenial being unable to integration
> test against projects who don't yet support Bionic. At the same
> time, projects which have switched to Bionic will start merging
> changes which only work on Bionic without realizing it, so that
> projects which test on Xenial can't use them. In short, you'll be
> broken either way. On top of that, you can end up with projects that
> don't get around to switching completely before release comes, and
> then they're stuck having to manage a test platform transition on a
> stable branch.

I understand Your point here but will option 2) from first email lead to the 
same issues then?

> -- 
> Jeremy Stanley
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] CI meeting on 13.11.2018 cancelled

[Slawomir Kaplonski]

Hi,

Due to summit in Berlin Neutron CI meeting on 13.11.2018 is cancelled. Next 
meeting will be as usual on 20.11.2018.

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [nova][neutron] boot server with more than one subnet selection question

[Slawomir Kaplonski]

Hi,

You can choose which subnet (and even IP address) should be used, see 
„fixed_ips” field in [1].
If You will not provide anything Neutron will choose for You one IPv4 address 
and one IPv6 address and in both cases it will be chosen randomly from 
available IPs from all subnets.

[1] 
https://developer.openstack.org/api-ref/network/v2/?expanded=create-port-detail#create-port

> Wiadomość napisana przez Chen CH Ji  w dniu 12.11.2018, 
> o godz. 13:44:
> 
> I have a network created like below:
>  
> 1 network with 3 subnets (1 ipv6 and 2 ipv4) ,when boot, whether I can select 
> subnet to boot from or the subnet will be force selected by the order the 
> subnet created? Any document or code can be  referred? Thanks
>  
> | fd0e2078-044d-4c5c-b114-3858631e6328 | private   | 
> a8184e4f-5165-4ea8-8ed8-b776d619af6e fd9b:c245:1aaa::/64 |
> |  |   | 
> b3ee7cad-c672-4172-a183-8e9f069bea31 10.0.0.0/26 |
> |  |   | 
> 9439abfd-afa2-4264-8422-977d725a7166 10.0.2.0/24 |
>  
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [all] All Hail our Newest Release Name - OpenStack Train

[Slawomir Kaplonski]

Hi,

I think it was published, see 
http://lists.openstack.org/pipermail/openstack/2018-November/047172.html

> Wiadomość napisana przez Jeremy Freudberg  w dniu 
> 14.11.2018, o godz. 06:12:
> 
> Hey Tony,
> 
> What's the reason for the results of the poll not being public?
> 
> Thanks,
> Jeremy
> On Tue, Nov 13, 2018 at 11:52 PM Tony Breeds  wrote:
>> 
>> 
>> Hi everybody!
>> 
>> As the subject reads, the "T" release of OpenStack is officially
>> "Train".  Unlike recent choices Train was the popular choice so
>> congrats!
>> 
>> Thanks to everybody who participated and help with the naming process.
>> 
>> Lets make OpenStack Train the release so awesome that people can't help
>> but choo-choo-choose to run it[1]!
>> 
>> 
>> Yours Tony.
>> [1] Too soon? Too much?
>> __
>> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] Stepping down from Neutron core team

[Slawomir Kaplonski]

Hi,

Thanks for all Your work in Neutron and good luck in Your new role.

— 
Slawek Kaplonski
Senior software engineer
Red Hat

> Wiadomość napisana przez Hirofumi Ichihara  w 
> dniu 02.12.2018, o godz. 15:08:
> 
> Hi all,
> 
> I’m stepping down from the core team because my role changed and I cannot 
> have responsibilities of neutron core.
> 
> My start of neutron was 5 years ago. I had many good experiences from neutron 
> team.
> Today neutron is great project. Neutron gets new reviewers, contributors and, 
> users.
> Keep on being a great community.
> 
> Thanks,
> Hirofumi
> __
> 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