[openstack-dev] [heat][nova] Does Heat support Nova micro versions

[Gary Kotton]

Hi,
Does heat support os-compute-api-version? Say for example I am using queens but 
have a use case via heat that requires a API parameter that was capped in the 
2.56 microversion.
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

[openstack-dev] [neutron] Core status

[Gary Kotton]

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

[openstack-dev] [Neutron] Bug status

[Gary Kotton]

Hi,
It has been a relatively quiet week and not many issues opened. There are a few 
bugs with IPv6 subnets. Most have missing information and I have asked the 
reporters for some extra information. Not any blockers are issues that are 
concerning.
Wishing everyone a productive PTG.
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

Re: [openstack-dev] [neutron] Bug deputy report week August 27 - September 2

[Gary Kotton]

Thanks for the update. I have taken the baton from the 2nd. Thankfully last few 
days have been quite.
A luta continua

From: Hirofumi Ichihara 
Reply-To: OpenStack List 
Date: Monday, September 3, 2018 at 11:54 AM
To: OpenStack List 
Subject: [openstack-dev] [neutron] Bug deputy report week August 27 - September 
2

Hi,

I was the bug deputy for the week of August 27 - September 2.

There is no Ctirical bug.

High:
https://bugs.launchpad.net/neutron/+bug/1789878
https://bugs.launchpad.net/neutron/+bug/1789846
https://bugs.launchpad.net/neutron/+bug/1789579
https://bugs.launchpad.net/neutron/+bug/1789434
https://bugs.launchpad.net/neutron/+bug/1789403

Medium:
https://bugs.launchpad.net/neutron/+bug/1790143
https://bugs.launchpad.net/neutron/+bug/1789499

New:
https://bugs.launchpad.net/neutron/+bug/1790084
 This is needed to triage by l3-dvr-backlog lieutenants.
https://bugs.launchpad.net/neutron/+bug/1790038
 This is needed to triage by l3-dvr-backlog lieutenants.
https://bugs.launchpad.net/neutron/+bug/1789334
 This is needed to triage by troubleshooting lieutenants or Osprofier forks.

Incomplete:
https://bugs.launchpad.net/neutron/+bug/1790023
https://bugs.launchpad.net/neutron/+bug/1789870

[openstack-dev] Pycharm license

[Gary Kotton]

Hi,
I understand that the community has an option to get licenses. Anyone have any 
information regarding this.
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

Re: [openstack-dev] [neutron] Bug deputy

[Gary Kotton]

Thanks!

From: James Anziano <janz...@us.ibm.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Thursday, May 17, 2018 at 6:21 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Cc: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] Bug deputy

Hey Gary, my turn is coming up soon (week of June 4th), I can jump the line a 
bit and cover you if you or anyone can cover my currently assigned week.

Thanks,
 - James Anziano

- Original message -
From: Gary Kotton <gkot...@vmware.com>
To: OpenStack List <openstack-dev@lists.openstack.org>
Cc:
Subject: [openstack-dev] [neutron] Bug deputy
Date: Thu, May 17, 2018 1:59 AM



Hi,

An urgent matter has come up this week. If possible, can someone please replace 
me.

Sorry

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



__
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

[Gary Kotton]

Hi,
An urgent matter has come up this week. If possible, can someone please replace 
me.
Sorry
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

[openstack-dev] [neutron] Bug deputy update

[Gary Kotton]

Hi,
A few minor bugs opened and one critical one - 
https://bugs.launchpad.net/neutron/+bug/1771293
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

Re: [openstack-dev] [openstack-infra] How to take over a project?

[Gary Kotton]

Hi,
You either need one of the ono core team or the neutron release team to add 
you. FYI - https://review.openstack.org/#/admin/groups/1001,members
Thanks
Gary

From: Sangho Shin 
Reply-To: OpenStack List 
Date: Tuesday, April 17, 2018 at 5:01 AM
To: OpenStack List 
Subject: [openstack-dev] [openstack-infra] How to take over a project?

Dear OpenStack Infra team,

I would like to know how to take over an OpenStack project.
I am a committer of the networking-onos project 
(https://github.com/openstack/networking-onos),
 and I would like to take over the project.
The current maintainer (cc’d) has already agreed with that.

Please let me know the process to take over (or change the maintainer of) the 
project.

BTW, it looks like even the current maintainer cannot create a new branch of 
the codes. How can we get the authority to create a new branch?

Thank you,

Sangho
__
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][vpnaas][fwaas][vmware-nsx] Stable/queens build sphinx docs broken

[Gary Kotton]

Maybe we should consider unblocking the stable versions at the moment and then 
enabling us to address in each project. 

On 4/16/18, 5:34 PM, "Jeremy Stanley" <fu...@yuggoth.org> wrote:

On 2018-04-16 10:49:17 +0000 (+0000), Gary Kotton wrote:
> We have seen that a number of stable projects that the sphinx docs
> is broken. The gate job returns ‘retry limit’. An example of the
> error is
> 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
> Does anyone have any idea how to address this?

Potential fixes seem to be adjusting the tools/tox_install.sh in
each of these projects to stop erroring when passed only a single
argument, or switch to relying on tox-siblings in those jobs so that
the neutron-horizon-hack role can be dropped from them entirely.
There is some discussion in https://review.openstack.org/561593 but
a centralized temporary workaround is somewhat risky since the
people in charge of reviewing any eventual revert will have a hard
time knowing when it's finally safe to do so.
-- 
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

Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx][ovn] Stable/queens build sphinx docs broken

[Gary Kotton]

Hi,
Here is an example - https://review.openstack.org/#/c/560893/
Thanks
Gary

From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, April 16, 2018 at 2:28 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx][ovn] 
Stable/queens build sphinx docs broken

Hi,
OVN too. Things were working on the 12th of April and something has changed 
since then.
Thanks
Gary

From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, April 16, 2018 at 1:49 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens 
build sphinx docs broken

Hi,
We have seen that a number of stable projects that the sphinx docs is broken. 
The gate job returns ‘retry limit’. An example of the error is 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
Does anyone have any idea how to address this?
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

Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx][ovn] Stable/queens build sphinx docs broken

[Gary Kotton]

Hi,
OVN too. Things were working on the 12th of April and something has changed 
since then.
Thanks
Gary

From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, April 16, 2018 at 1:49 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens 
build sphinx docs broken

Hi,
We have seen that a number of stable projects that the sphinx docs is broken. 
The gate job returns ‘retry limit’. An example of the error is 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
Does anyone have any idea how to address this?
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

[openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens build sphinx docs broken

[Gary Kotton]

Hi,
We have seen that a number of stable projects that the sphinx docs is broken. 
The gate job returns ‘retry limit’. An example of the error is 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
Does anyone have any idea how to address this?
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

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

[Gary Kotton]

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" <skapl...@redhat.com> 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 <gkot...@vmware.com> 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

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

[Gary Kotton]

Please see https://review.openstack.org/561443

On 4/16/18, 2:31 AM, "IWAMOTO Toshihiro" <iwam...@valinux.co.jp> 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 <amot...@gmail.com>
> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
> Date: Sunday, April 15, 2018 at 12:43 PM
> To: OpenStack List <openstack-dev@lists.openstack.org>
> 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" 
<gkot...@vmware.com<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/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<http://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",
 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<http://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

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

[Gary Kotton]

Hi,
That sounds reasonable. I wonder if the RYU folk can chime in here.
Thanks
Gary

From: Akihiro MOTOKI <amot...@gmail.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Sunday, April 15, 2018 at 12:43 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
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" <gkot...@vmware.com<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_module_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/lower-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/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<http://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<http://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<http://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.5/site-packages/ryu/lib/packet/bgp.py<http://git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/lib/packet/bgp.py>",
 line 52, in \nfrom ryu.utils import binary_str\n  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/utils.py<http://git.openstack.org/openstack/n

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

[Gary Kotton]

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

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

[Gary Kotton]

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_module_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",
 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",
 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.5/site-packages/ryu/lib/packet/bgp.py",
 line 52, in \nfrom ryu.utils import binary_str\n  File 
"/home/zuul/src/git.openstack.org/openstack/neutron-dynamic-routing/.tox/lower-constraints/lib/python3.5/site-packages/ryu/utils.py",
 line 23, in \nfrom pip import req as pip_req\nImportError: cannot 
import name \'req\'\n'

Any suggestions?
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

[openstack-dev] [neutron][horizon][l2gw] Unable to create a floating IP

[Gary Kotton]

Hi,
From Queens onwards we have a issue with horizon and L2GW. We are unable to 
create a floating IP. This does not occur when using the CLI only via horizon. 
The error received is
‘Error: User does not have admin privileges: Cannot GET resource for non admin 
tenant. Neutron server returns request_ids: 
['req-f07a3aac-0994-4d3a-8409-1e55b374af9d']’
This is due to: 
https://github.com/openstack/networking-l2gw/blob/master/networking_l2gw/db/l2gateway/l2gateway_db.py#L316
This worked in Ocata and not sure what has changed since then ☹. Maybe in the 
past the Ocata quota’s were not checking L2gw.
Any 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

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

[Gary Kotton]

Hi,
There are some tempest tests that check realization of resources on the 
networking platform and connectivity. Here things are challenging as each 
networking platform may be more restrictive than the upstream ML2 plugin. My 
thinking here is that we should leverage the tempest plugins for each 
networking platform and they can overwrite the problematic tests and address 
them as suitable for the specific plugin.
Thanks
Gary

From: Miguel Angel Ajo Pelayo 
Reply-To: OpenStack List 
Date: Saturday, April 7, 2018 at 8:56 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] [OVN] Tempest API / Scenario tests and 
OVN metadata

this issue isn't only for networking ovn, please note that it happens with a 
flew other vendor plugins (like nsx), at least this is something we have found 
in downstream certifications.

Cheers,
On Sat, Apr 7, 2018, 12:36 AM Daniel Alvarez 
> wrote:


> On 6 Apr 2018, at 19:04, Sławek Kapłoński 
> > wrote:
>
> Hi,
>
> Another idea is to modify test that it will:
> 1. Check how many ports are in tenant,
> 2. Set quota to actual number of ports + 1 instead of hardcoded 1 as it is 
> now,
> 3. Try to add 2 ports - exactly as it is now,
>
Cool, I like this one :-)
Good idea.

> I think that this should be still backend agnostic and should fix this 
> problem.
>
>> Wiadomość napisana przez Sławek Kapłoński 
>> > w dniu 06.04.2018, o godz. 
>> 17:08:
>>
>> Hi,
>>
>> I don’t know how networking-ovn is working but I have one question.
>>
>>
>>> Wiadomość napisana przez Daniel Alvarez Sanchez 
>>> > w dniu 06.04.2018, o 
>>> godz. 15:30:
>>>
>>> Hi,
>>>
>>> Thanks Lucas for writing this down.
>>>
>>> On Thu, Apr 5, 2018 at 11:35 AM, Lucas Alvares Gomes 
>>> > wrote:
>>> Hi,
>>>
>>> The tests below are failing in the tempest API / Scenario job that
>>> runs in the networking-ovn gate (non-voting):
>>>
>>> neutron_tempest_plugin.api.admin.test_quotas_negative.QuotasAdminNegativeTestJSON.test_create_port_when_quotas_is_full
>>> neutron_tempest_plugin.api.test_routers.RoutersIpV6Test.test_router_interface_status
>>> neutron_tempest_plugin.api.test_routers.RoutersTest.test_router_interface_status
>>> neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_prefixlen
>>> neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_quota
>>> neutron_tempest_plugin.api.test_subnetpools.SubnetPoolsTest.test_create_subnet_from_pool_with_subnet_cidr
>>>
>>> Digging a bit into it I noticed that with the exception of the two
>>> "test_router_interface_status" (ipv6 and ipv4) all other tests are
>>> failing because the way metadata works in networking-ovn.
>>>
>>> Taking the "test_create_port_when_quotas_is_full" as an example. The
>>> reason why it fails is because when the OVN metadata is enabled,
>>> networking-ovn will metadata port at the moment a network is created
>>> [0] and that will already fulfill the quota limit set by that test
>>> [1].
>>>
>>> That port will also allocate an IP from the subnet which will cause
>>> the rest of the tests to fail with a "No more IP addresses available
>>> on network ..." error.
>>>
>>> With ML2/OVS we would run into the same Quota problem if DHCP would be
>>> enabled for the created subnets. This means that if we modify the current 
>>> tests
>>> to enable DHCP on them and we account this extra port it would be valid for
>>> all networking-ovn as well. Does it sound good or we still want to isolate 
>>> quotas?
>>
>> If DHCP will be enabled for networking-ovn, will it use one more port also 
>> or not? If so then You will still have the same problem with DHCP as in 
>> ML2/OVS You will have one port created and for networking-ovn it will be 2 
>> ports.
>> If it’s not like that then I think that this solution, with some comment in 
>> test code why DHCP is enabled should be good IMO.
>>
>>>
>>> This is not very trivial to fix because:
>>>
>>> 1. Tempest should be backend agnostic. So, adding a conditional in the
>>> tempest test to check whether OVN is being used or not doesn't sound
>>> correct.
>>>
>>> 2. Creating a port to be used by the metadata agent is a core part of
>>> the design implementation for the metadata functionality [2]
>>>
>>> So, I'm sending this email to try to figure out what would be the best
>>> approach to deal with this problem and start working towards having
>>> that job to be voting in our gate. Here are some ideas:
>>>
>>> 1. Simple disable the tests that are affected by the metadata approach.
>>>
>>> 2. Disable metadata for the tempest API / Scenario tests (here's a
>>> test patch doing it [3])
>>>
>>> IMHO, we don't want 

Re: [openstack-dev] [nova] VMware NSX CI - no longer running?

[Gary Kotton]

Hi,
Here is an example where the CI has run on a recent patch - yesterday - 
https://review.openstack.org/557256
Thanks
Gary

On 3/29/18, 1:04 PM, "melanie witt"  wrote:

On Thu, 29 Mar 2018 10:44:52 +0300, Radoslav Gerganov wrote:
> On 28.03.2018 19:07, melanie witt wrote:
>> We were reviewing a bug fix for the vmware driver [0] today and we 
noticed it appears that the VMware NSX CI is no longer running, not even on 
only the nova/virt/vmwareapi/ tree.
>>
>>  From the third-party CI dashboard, I see some claims of it running but 
when I open the patches, I don't see any reporting from VMware NSX CI [1].
>>
>> Can anyone from the vmware subteam comment on whether or not the vmware 
third-party CI is going to be fixed or if it has been abandoned?
>>
> 
> While running the VMware CI continues to be a challenge, I must say this 
patch fixes a regression introduced by Matt Riedemann's patch:
> 
> https://review.openstack.org/#/c/549411/
> 
> for which the VMware CI clearly indicated there was a problem and 
nevertheless the core team submitted it.
> Before blaming the CI for not voting enough, the core team should start 
taking into account existing CI votes.
> It'd be nice also to include VMware driver maintainers as reviewers when 
making changes to the VMware driver.

Thank you for bringing the root cause to our attention and I'm sorry we 
made a mistake that broke the driver. You are right that the VMware CI 
vote should have been taken into consideration and that the VMware 
subteam members should have been added as reviewers on the patch.

It was not my intention to blame the VMware CI for not voting enough. I 
just wanted to know what happened to it and whether or not it is being 
maintained.

I would like to see the VMware CI running again and it need only run on 
changes under the nova/virt/vmwareapi/ tree, to save on your resources. 
And on our side, I'd like us to add VMware subteam members to VMware 
driver patch reviews (I believe most of the active team members are 
listed on the priorities etherpad [0]) and to be sure we consult VMware 
CI votes when we review.

Best,
-melanie

[0] https://etherpad.openstack.org/p/rocky-nova-priorities-tracking L256




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


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

Re: [openstack-dev] Adding Brian Haley to the Neutron Drivers team

[Gary Kotton]

+1

From: Miguel Lavalle 
Reply-To: OpenStack List 
Date: Thursday, March 22, 2018 at 6:26 PM
To: OpenStack List 
Subject: [openstack-dev] Adding Brian Haley to the Neutron Drivers team

Hi Neutrinos,
As we all know, the Neutron Drivers team plays a crucial role in helping the 
community to evolve the OpenStack Networking architecture to meet the needs of 
our current and future users [1]. To strengthen this team, I have decided to 
add Brian Haley to it. Brian has two decades of experience in open source 
networking technology. He joined the OpenStack community contributing code to 
nova-network in the Diablo release. His first Neutron commit (known as Quantum 
at the time) dates back to March of 2013 [2]. Since then, his many 
contributions include the implementation and evolution of our L3 and DVR code. 
He is one of our most active core reviewers and a prolific contributor of code 
to our reference implementation. I am very confident that Brian will be a 
continuous source of knowledge, experience and valuable insight to the Drivers 
team.
Best regards
Miguel


[1] 
https://docs.openstack.org/neutron/pike/contributor/policies/neutron-teams.html#drivers-team
[2] https://review.openstack.org/#/c/25564/
__
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] [requirements][l2gw] Latest requirements

[Gary Kotton]

Hi,
We have a problem with the l2gw tags. The requirements file indicates that we 
should be pulling in >=12.0.0 and in fact its pulling networking_l2gw-2016.1.0
Please see 
http://207.189.188.190/logs/neutron/554292/4/tempest-api-vmware-tvd-t/logs/stack.sh.log.txt.gz#_2018-03-22_08_56_03_905
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

Re: [openstack-dev] [requirements][neutron] Depending on pypi versions

[Gary Kotton]

The change will need to be in all of the decomposed projects - 
http://codesearch.openstack.org/?q=install_cmd%20-U=nope==
Good catch!

On 3/19/18, 3:18 PM, "Gary Kotton" <gkot...@vmware.com> wrote:

Thanks!! Will check if it now

On 3/19/18, 3:15 PM, "Andreas Jaeger" <a...@suse.com> wrote:
    
    On 2018-03-19 14:01, Gary Kotton wrote:
> The issue is that since the change below -
> https://review.openstack.org/553045 - we are not picking up the latest
> neutron master code.

I see neutron installed:


http://logs.openstack.org/45/553045/1/gate/openstack-tox-pep8/5347981/job-output.txt.gz#_2018-03-15_13_58_12_552258

But later it's downgraded - like it's done for the other requirements
you have. So, this uncovered a problem in your install.

pip install -U breaks it, please double check that this does the right
thing:

https://review.openstack.org/554222

Andreas

>  
> 
> *From: *Thomas Morin <thomas.mo...@orange.com>
> *Organization: *Orange S.A.
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Monday, March 19, 2018 at 1:46 PM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [requirements][neutron] Depending on 
pypi
> versions
> 
>  
> 
> Hi Gary,
> 
>  
> 
> See
> 
> 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128311.html
> 
>  
> 
>> Note that thanks to the tox-siblings feature, we really continue to
> 
>> install neutron and horizon from git - and not use the versions in
> 
>> the global-requirements constraints file,
> 
>  
> 
> I think it is worth adding a comment in (test-)requirements.txt that 
the
> OpenStack CI is overriding the version and uses git.
> 
>  
> 
> -Thomas
> 
>  
> 
>  
> 
> Gary Kotton, 2018-03-19 11:25:
> 
> Hi,
> 
> The change
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_requirements_commit_35653e8c5044bff1059f50a82b6065176eea=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=438_Ni4AJ-nteg3SAstWzssFEcYN8k5BoSslcDtkSEU=nkowIZ6GVGMJAfMtR4XliFZhODdtly2gsBTr8k9wFFY=
> has created some issues with decomposed neutron plugins. Let me 
try
> and give an example to explain.
> 
> Say for example a patch landed in neutron master that exposed
> feature X. Now if a decomposed plugin wants to consume this it 
will
> fail as the decomposed plugin will pull in the latest tag.
> 
> Does this mean for each new feature that we wish to consume we 
will
> need to update neutron tags?
> 
> Please advise.
> 
> Thanks
> 
> Gary
> 
> 
__
> 
> OpenStack Development Mailing List (not for usage questions)
> 
> Unsubscribe: openstack-dev-requ...@lists.openstack.org
> 
<mailto: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
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126



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

Re: [openstack-dev] [requirements][neutron] Depending on pypi versions

[Gary Kotton]

Thanks!! Will check if it now

On 3/19/18, 3:15 PM, "Andreas Jaeger" <a...@suse.com> wrote:

On 2018-03-19 14:01, Gary Kotton wrote:
> The issue is that since the change below -
> https://review.openstack.org/553045 - we are not picking up the latest
> neutron master code.

I see neutron installed:


http://logs.openstack.org/45/553045/1/gate/openstack-tox-pep8/5347981/job-output.txt.gz#_2018-03-15_13_58_12_552258

But later it's downgraded - like it's done for the other requirements
you have. So, this uncovered a problem in your install.

pip install -U breaks it, please double check that this does the right
thing:

https://review.openstack.org/554222

Andreas

>  
> 
> *From: *Thomas Morin <thomas.mo...@orange.com>
> *Organization: *Orange S.A.
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Monday, March 19, 2018 at 1:46 PM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [requirements][neutron] Depending on pypi
> versions
> 
>  
> 
> Hi Gary,
> 
>  
> 
> See
> 
> http://lists.openstack.org/pipermail/openstack-dev/2018-March/128311.html
> 
>  
> 
>> Note that thanks to the tox-siblings feature, we really continue to
> 
>> install neutron and horizon from git - and not use the versions in
> 
>> the global-requirements constraints file,
> 
>  
> 
> I think it is worth adding a comment in (test-)requirements.txt that the
> OpenStack CI is overriding the version and uses git.
> 
>  
> 
> -Thomas
> 
>  
> 
>  
> 
> Gary Kotton, 2018-03-19 11:25:
> 
> Hi,
> 
> The change
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_requirements_commit_35653e8c5044bff1059f50a82b6065176eea=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=438_Ni4AJ-nteg3SAstWzssFEcYN8k5BoSslcDtkSEU=nkowIZ6GVGMJAfMtR4XliFZhODdtly2gsBTr8k9wFFY=
> has created some issues with decomposed neutron plugins. Let me try
> and give an example to explain.
> 
> Say for example a patch landed in neutron master that exposed
> feature X. Now if a decomposed plugin wants to consume this it will
> fail as the decomposed plugin will pull in the latest tag.
> 
> Does this mean for each new feature that we wish to consume we will
> need to update neutron tags?
> 
> Please advise.
> 
> Thanks
> 
> Gary
> 
> 
__
> 
> OpenStack Development Mailing List (not for usage questions)
> 
> Unsubscribe: openstack-dev-requ...@lists.openstack.org
> <mailto: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
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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


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

Re: [openstack-dev] [requirements][neutron] Depending on pypi versions

[Gary Kotton]

The issue is that since the change below - https://review.openstack.org/553045 
- we are not picking up the latest neutron master code.

From: Thomas Morin <thomas.mo...@orange.com>
Organization: Orange S.A.
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, March 19, 2018 at 1:46 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [requirements][neutron] Depending on pypi versions

Hi Gary,

See
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128311.html

> Note that thanks to the tox-siblings feature, we really continue to
> install neutron and horizon from git - and not use the versions in
> the global-requirements constraints file,

I think it is worth adding a comment in (test-)requirements.txt that the 
OpenStack CI is overriding the version and uses git.

-Thomas


Gary Kotton, 2018-03-19 11:25:
Hi,
The change 
https://github.com/openstack/requirements/commit/35653e8c5044bff1059f50a82b6065176eea
 has created some issues with decomposed neutron plugins. Let me try and give 
an example to explain.
Say for example a patch landed in neutron master that exposed feature X. Now if 
a decomposed plugin wants to consume this it will fail as the decomposed plugin 
will pull in the latest tag.
Does this mean for each new feature that we wish to consume we will need to 
update neutron tags?
Please advise.
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [requirements][neutron] Depending on pypi versions

[Gary Kotton]

Hi,
The change 
https://github.com/openstack/requirements/commit/35653e8c5044bff1059f50a82b6065176eea
 has created some issues with decomposed neutron plugins. Let me try and give 
an example to explain.
Say for example a patch landed in neutron master that exposed feature X. Now if 
a decomposed plugin wants to consume this it will fail as the decomposed plugin 
will pull in the latest tag.
Does this mean for each new feature that we wish to consume we will need to 
update neutron tags?
Please advise.
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

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Gary Kotton]

Thanks for the clarification. 

On 2/28/18, 3:22 PM, "Akihiro Motoki" <amot...@gmail.com> wrote:

Hi Gary,

You are talking about vender extension support in OSC, but this is
about python bindings.
I believe this is another topic. Commands implemented in OSC repo
already consumes OpenStack SDK, so the proposed change just increases
the number of python bindings supported in SDK.

Regarding the topic of third-party extension support after OSC
transition, possible options in my mind is to keep "neutron" CLI, or
to add some command which handle general network resources as
neutronclient OSC plugin. It is a compromise considering the current
neutron API. Note that OpenStackSDK proxy object supports
keystoneauth.Adapter, so even after migrating to OpenStackSDK, this
does not block arbitrary attributes immediately even though they are
things we would like to avoid. If you and/or boden are interested in
implementing so-called "generic network resource" commands in Neutron
OSC plugin, I can help the effort (as it speed up neutron CLI
deprecation).

Akihiro

2018-02-26 13:39 GMT+00:00 Gary Kotton <gkot...@vmware.com>:
> One of the concerns here is that the openstack client does not enable one 
to configure extensions that are not part of the core reference architecture. 
So any external third part that tries to have any etension added will not be 
able to leverage the openstack client. This is a major pain point.
>
>
> On 2/26/18, 1:26 PM, "Monty Taylor" <mord...@inaugust.com> wrote:
>
> On 02/26/2018 10:55 AM, Rabi Mishra wrote:
> > On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor <mord...@inaugust.com
> > <mailto:mord...@inaugust.com>> wrote:
> >
> > On 02/26/2018 09:57 AM, Akihiro Motoki wrote:
> >
> > Hi neutron and openstacksdk team,
> >
> > This mail proposes to change the first priority of 
neutron-related
> > python binding to OpenStack SDK rather than neutronclient 
python
> > bindings.
> > I think it is time to start this as OpenStack SDK became a 
official
> > project in Queens.
> >
> >
> > ++
> >
> >
> > [Current situations and problems]
> >
> > Network OSC commands are categorized into two parts: OSC and
> > neutronclient OSC plugin.
> > Commands implemented in OSC consumes OpenStack SDK
> > and commands implemented as neutronclient OSC plugin 
consumes
> > neutronclient python bindings.
> > This brings tricky situation that some features are 
supported
> > only in
> > OpenStack SDK and some features are supported only in 
neutronclient
> > python bindings.
> >
> > [Proposal]
> >
> > The proposal is to implement all neutron features in 
OpenStack
> > SDK as
> > the first citizen,
> > and the neutronclient OSC plugin consumes corresponding
> > OpenStack SDK APIs.
> >
> > Once this is achieved, users of OpenStack SDK users can see 
all
> > network related features.
> >
> > [Migration plan]
> >
> > The migration starts from Rocky (if we agree).
> >
> > New features should be supported in OpenStack SDK and
> > OSC/neutronclient OSC plugin as the first priority. If new 
feature
> > depends on neutronclient python bindings, it can be 
implemented in
> > neutornclient python bindings first and they are ported as 
part of
> > existing feature transition.
> >
> > Existing features only supported in neutronclient python
> > bindings are
> > ported into OpenStack SDK,
> > and neutronclient OSC plugin will consume them once they are
> > implemented in OpenStack SDK.
> >
> >
> > I think this is a great idea. We've got a bunch of good
> > functional/integrations tests in the sdk gate as well that we 
can
> > start running on neutron patches so that we don't lose 
cross-gating.
&g

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Gary Kotton]

One of the concerns here is that the openstack client does not enable one to 
configure extensions that are not part of the core reference architecture. So 
any external third part that tries to have any etension added will not be able 
to leverage the openstack client. This is a major pain point.


On 2/26/18, 1:26 PM, "Monty Taylor"  wrote:

On 02/26/2018 10:55 AM, Rabi Mishra wrote:
> On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor  > wrote:
> 
> On 02/26/2018 09:57 AM, Akihiro Motoki wrote:
> 
> Hi neutron and openstacksdk team,
> 
> This mail proposes to change the first priority of neutron-related
> python binding to OpenStack SDK rather than neutronclient python
> bindings.
> I think it is time to start this as OpenStack SDK became a 
official
> project in Queens.
> 
> 
> ++
> 
> 
> [Current situations and problems]
> 
> Network OSC commands are categorized into two parts: OSC and
> neutronclient OSC plugin.
> Commands implemented in OSC consumes OpenStack SDK
> and commands implemented as neutronclient OSC plugin consumes
> neutronclient python bindings.
> This brings tricky situation that some features are supported
> only in
> OpenStack SDK and some features are supported only in 
neutronclient
> python bindings.
> 
> [Proposal]
> 
> The proposal is to implement all neutron features in OpenStack
> SDK as
> the first citizen,
> and the neutronclient OSC plugin consumes corresponding
> OpenStack SDK APIs.
> 
> Once this is achieved, users of OpenStack SDK users can see all
> network related features.
> 
> [Migration plan]
> 
> The migration starts from Rocky (if we agree).
> 
> New features should be supported in OpenStack SDK and
> OSC/neutronclient OSC plugin as the first priority. If new feature
> depends on neutronclient python bindings, it can be implemented in
> neutornclient python bindings first and they are ported as part of
> existing feature transition.
> 
> Existing features only supported in neutronclient python
> bindings are
> ported into OpenStack SDK,
> and neutronclient OSC plugin will consume them once they are
> implemented in OpenStack SDK.
> 
> 
> I think this is a great idea. We've got a bunch of good
> functional/integrations tests in the sdk gate as well that we can
> start running on neutron patches so that we don't lose cross-gating.
> 
> [FAQ]
> 
> 1. Will neutornclient python bindings be removed in future?
> 
> Different from "neutron" CLI, as of now, there is no plan to
> drop the
> neutronclient python bindings.
> Not a small number of projects consumes it, so it will be
> maintained as-is.
> The only change is that new features are implemented in
> OpenStack SDK first and
> enhancements of neutronclient python bindings will be minimum.
> 
> 2. Should projects that consume neutronclient python bindings 
switch
> to OpenStack SDK?
> 
> Necessarily not. It depends on individual projects.
> Projects like nova that consumes small set of neutron features can
> continue to use neutronclient python bindings.
> Projects like horizon or heat that would like to support a wide
> range
> of features might be better to switch to OpenStack SDK.
> 
> 
> We've got a PTG session with Heat to discuss potential wider-use of
> SDK (and have been meaning to reach our to horizon as well) Perhaps
> a good first step would be to migrate the
> heat.engine.clients.os.neutron:NeutronClientPlugin code in Heat from
> neutronclient to SDK.
> 
> 
> Yeah, this would only be possible after openstacksdk supports all 
> neutron features as mentioned in the proposal.

++

> Note: We had initially added the OpenStackSDKPlugin in heat to support 
> neutron segments and were thinking of doing all new neutron stuff with 
> openstacksdk. However, we soon realised that it's not possible when 
> implementing neutron trunk support and had to drop the idea.

Maybe we start converting one thing at a time and when we find something 
sdk doesn't support we should be able to add it pretty quickly... which 
should then also wind up improving the sdk layer.

Re: [openstack-dev] [neutron][l2gw] stable/queens tripleo issues

[Gary Kotton]

Thanks!! When its ready we can add it again.
Thank you!

From: Emilien Macchi <emil...@redhat.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Tuesday, February 20, 2018 at 9:14 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][l2gw] stable/queens tripleo issues

Hey Gary :-)

Yeah our CI isn't ready yet for stable/queens, sorry for that.
I propose to disable TripleO jobs in stable/queens for l2gw project: 
https://review.openstack.org/546059

Hopefully that helps!

Cheers,

On Mon, Feb 19, 2018 at 11:07 PM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
At the moment the stable/queens branch is broken due to the tripleo CI test 
failing [i]. Does anyone have any hints here on what we should look at? I am 
not sure if this is with ansible/centos…
Thanks
Gary
[i] 
http://logs.openstack.org/88/543188/2/check/tripleo-ci-centos-7-scenario004-multinode-oooq-container/9bc3b75/

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



--
Emilien Macchi
__
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][l2gw] stable/queens tripleo issues

[Gary Kotton]

Hi,
At the moment the stable/queens branch is broken due to the tripleo CI test 
failing [i]. Does anyone have any hints here on what we should look at? I am 
not sure if this is with ansible/centos…
Thanks
Gary
[i] 
http://logs.openstack.org/88/543188/2/check/tripleo-ci-centos-7-scenario004-multinode-oooq-container/9bc3b75/
__
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][lbaas][neutron-lbaas][octavia] Announcing the deprecation of neutron-lbaas and neutron-lbaas-dashboard

[Gary Kotton]

Hi,
I have a number of issues with this:
1. I do not think that we should mark this as deprecated until we have a clear 
and working migration patch. Let me give an example. Say I have a user who is 
using Pike or Queens and has N LBaaS load balancers up and running. What if we 
upgrade to T and there is no LBaaS, only Octavia. What is the migration path 
here? Maybe I have missed this and would be happy to learn how this was done.
2. I think that none of the load balancing vendors have code in Octavia and 
this may be a problem (somewhat related to #1). I guess that there is enough 
warning but this is still concerning
3. The migration from V1 to V2 was not successful. So, I have some concerns 
about going to a new service completely.
I prefer that we hold off on this until there is a clear picture. 
Thanks
Gary

On 2/1/18, 9:22 AM, "Andreas Jaeger"  wrote:

On 2018-01-31 22:58, Akihiro Motoki wrote:
> I don't think we need to drop translation support NOW (at least for
> neutron-lbaas-dashboard).
> There might be fixes which affects translation and/or there might be
> translation improvements.
> I don't think a deprecation means no translation fix any more. It
> sounds too aggressive.
> Is there any problem to keep translations for them?

Reading the whole FAQ - since bug fixes are planned, translations can
merge back. So, indeed we can keep translation infrastructure set up.

I recommend to translators to remove neutron-lbaas-dashboard from the
priority list,

Andreas

> Akihiro
> 
> 2018-02-01 3:28 GMT+09:00 Andreas Jaeger :
>> In that case, I suggest to remove translation jobs for these 
repositories,
>>
>> Andreas
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
>> 
__
>> 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
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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


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

[openstack-dev] [neutron][dynamic-routing] Broken unit tests

[Gary Kotton]

Hi,
Can cores please look at https://review.openstack.org/543208. We are currently 
blocked on master and stable/queens with this.
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

[openstack-dev] [Neutron] Bug deputy report

[Gary Kotton]

Hi,
Things have been relatively quiet. There are two bugs:
1. https://bugs.launchpad.net/neutron/+bug/1743480 - I think that we can 
leverage tags here so that should address the issue. Would be interesting to 
know what others thing.
2. https://bugs.launchpad.net/neutron/+bug/1743552 - patch in review 
https://review.openstack.org/#/c/534263/
I need to drop off bug duty on Thursday night so if someone can please swap me 
for Friday.
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

[openstack-dev] [infra] Gerrit issues

[Gary Kotton]

Hi,
Anyone else experience problems accessing gerrit?
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

Re: [Openstack] Issues Understanding Neutron Networking Layout

[Gary Kotton]

Hi,
Everything is now logged in syslog. You can use journalctl to get the logs – 
please see:
https://docs.openstack.org/devstack/latest/systemd.html
For example:
sudo journalctl -a --unit devstack@q-svc.service
Thanks
Gary

From: Trinath Somanchi 
Date: Tuesday, December 19, 2017 at 12:40 PM
To: "d.l...@surrey.ac.uk" , 
"openstack@lists.openstack.org" 
Subject: Re: [Openstack] Issues Understanding Neutron Networking Layout

Check /opt/stack/logs ?

/
   Trinath Somanchi | HSDC | NXP INDIA

From: d.l...@surrey.ac.uk [mailto:d.l...@surrey.ac.uk]
Sent: Tuesday, December 19, 2017 3:59 PM
To: Trinath Somanchi ; openstack@lists.openstack.org
Subject: RE: Issues Understanding Neutron Networking Layout

Can you tell me where to look?   None of the usual “screen” logs are there with 
the latest DevStack and the system doesn’t seem to be populating any of the 
/var/log locations etiher.

David

From: Trinath Somanchi [mailto:trinath.soman...@nxp.com]
Sent: 19 December 2017 08:51
To: Lake D Mr (PG/R - Elec Electronic Eng) 
>; 
openstack@lists.openstack.org
Subject: RE: Issues Understanding Neutron Networking Layout

Can you check neutron server/agent logs for exact error to debug ?

/
   Trinath Somanchi | HSDC | NXP INDIA

From: d.l...@surrey.ac.uk 
[mailto:d.l...@surrey.ac.uk]
Sent: Tuesday, December 19, 2017 2:02 PM
To: openstack@lists.openstack.org
Subject: [Openstack] Issues Understanding Neutron Networking Layout

Hello

I’m trying to create a Pike system with Carbon ODL integration using a single 
Controller node and a single Compute node.

The Controller Node has a single 1GE NIC to the management network.  It will 
not run any compute or network services.

The Compute Node has a single 1GE NIC to the management network and 4 x 10GE 
NICS for public network access.  I will be creating 4 VXNets, 4 routers, 4 
pools of public floating IP addresses.

I have built the machines using DevStack (configs attached).

It seems that even though the Controller node will have no network/compute 
functions, I still need to declare the ODL and networking parts in the 
local.conf on the controller.   But this implies that the Controller also has 
to have access to the 10GE network which I don’t want or need.

I have created 4 OVS bridges on both the Controller and the Compute nodes but 
the corresponding NICs on the Controller are not connected anywhere.  The 
bridges are br-physnet1 to br-physnet4 and these link to em1 to em4 
respectively.  Only the em1 – em4 on the Compute node are actually active.

I then create the VXLAN, router and DHCP agent.

However, when I try to start an instance on the Compute node post DevStack 
installation, I hit an issue where the GUI tells me it has been “unable to 
allocate network.”

I see no attempt to create a VXLAN between the Controller and the Compute node. 
  IPTables is open and a sniff on port 4789 reveals no traffic back and forth 
(on either side).

Does the Controller need to be physically connected to the same public facing 
networks as the Compute node?

Alternatively, how can I get all the Networking functions to run in the Compute 
node so that the Controller is just a controller?

Thanks

David
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [neutron] Stepping down from core

[Gary Kotton]

Armando, wishing you the best in the future.
Forza Juve!

From: Hirofumi Ichihara 
Reply-To: OpenStack List 
Date: Tuesday, December 19, 2017 at 12:28 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] Stepping down from core

Hi Armando,

It's been a great pleasure working with you. We appreciate your hard work and 
dedication.
Best wishes and good luck at your new commitments.

Thanks,
Hirofumi

2017-12-16 4:01 GMT+09:00 Armando M. 
>:
Hi neutrinos,

To some of you this email may not come as a surprise.

During the past few months my upstream community engagements have been more and 
more sporadic. While I tried hard to stay committed and fulfill my core 
responsibilities I feel like I failed to retain the level of quality and 
consistency that I would have liked ever since I stepped down from being the 
Neutron PTL back at the end of Ocata.

I stated many times when talking to other core developers that being core is a 
duty rather than a privilege, and I personally feel like it's way overdue for 
me to recognize on the mailing list that it's the time that I state officially 
my intention to step down due to other commitments.

This does not mean that I will disappear tomorrow. I'll continue to be on 
neutron IRC channels, support the neutron team, being the release liasion for 
Queens, participate at meetings, and be open to providing feedback to anyone 
who thinks my opinion is still valuable, especially when dealing with the 
neutron quirks for which I might be (git) blamed :)

Cheers,
Armando


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

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

[openstack-dev] [neutron][neutron-dynamic-routing] Floating IP create is broken

[Gary Kotton]

Hi,
The patch 
088e317cd2dd8488feb29a4fa6600227d1810479
 has broken floating IP creation. This breaks the dynamic routing gating.
I have opened a bug and have posted a patch to address.
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

Re: [openstack-dev] [etsinfv][neutron][gap-09]: No state for subnets

[Gary Kotton]

Hi,
Can you please elaborate more about the subnet state? FYI - 
https://wiki.openstack.org/wiki/Neutron/APIv2-specification#Subnet
Thanks
Gary

From: "Csatari, Gergely (Nokia - HU/Budapest)" 
Reply-To: OpenStack List 
Date: Wednesday, December 6, 2017 at 3:13 PM
To: OpenStack List 
Subject: [openstack-dev] [etsinfv][neutron][gap-09]: No state for subnets

Hi,

During the discussions in NFV#20 about the subnet state we argeed, that we 
should remove the state from the specification of subnets in IFA005 and IFA006. 
This invalidates [GAP-09] in [1].

Br,
Gerg0

[1]: https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained
__
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] Propose Slawek Kaplonski for Neutron core

[Gary Kotton]

+1

Welcome to the team!

From: Miguel Lavalle 
Reply-To: OpenStack List 
Date: Wednesday, November 29, 2017 at 9:21 PM
To: OpenStack List 
Subject: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

Hi Neutron Team,

I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek has 
been an active contributor to the project since the Mitaka cycle. He has been 
instrumental in the development of the QoS capabilities in Neutron, becoming 
the lead of the sub-team focused on that set of features. More recently, he has 
collaborated in the implementation of OVO and is an active participant in the 
CI sub-team. His number of code reviews during the Queens cycle is on par with 
the leading core members of the team: 
http://stackalytics.com/?module=neutron

In my opinion, his efforts are highly valuable to the team and we will be very 
lucky to have him as a fully voting core.

I will keep this nomination open for a week as customary,

Thank you,

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

Re: [openstack-dev] [Neutron] any flow-charts ?

[Gary Kotton]

Hi,
Please see 
https://docs.openstack.org/security-guide/networking/architecture.html for a 
starting point.
Thanks
Gary

From: Guru Desai 
Reply-To: OpenStack List 
Date: Saturday, November 25, 2017 at 1:00 PM
To: OpenStack List 
Subject: [openstack-dev] [Neutron] any flow-charts ?

Hello All,

I am new kid in the block !!   looking for info on few things of  
Neutron(pike). Apologies for such basic questions..

i am curious to understand how is the flow when a user creates a network 
through cli/ui.  what happens in the background ? are there some flow-charts 
about such things of neutron..

Any pointers would be very helpful.

Thanks
GD
__
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] Debug tool

[Gary Kotton]

Hi,
Out of interest is anyone using this tool? If so can you please let us know. 
This was marked as deprecated in about 18months ago in favor of a tool that was 
an idea that never actually materialized.
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

Re: [Openstack] Regarding devstack service restart

[Gary Kotton]

Please see https://docs.openstack.org/devstack/latest/systemd.html

From: Suraj Davanagere Basavaraj 
Date: Tuesday, October 17, 2017 at 12:24 PM
To: "openstack@lists.openstack.org" 
Subject: [Openstack] Regarding devstack service restart

Hello,

We read in Openstack discussion about service restart in devstack. We got to 
know that services are running in terms of screens. We tried to use the command 
"screen -r" and got the following error,

stack@ubuntu:/home/ubuntu/devstack$ screen -r
Cannot open your terminal '/dev/pts/28' - please check.

Could you please let us know how to view screens to restart devstack service.
Thank you.



Regards
Suraj
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [all][infra] Zuul v3 rollout, the sequel

[Gary Kotton]

Hi,
At the moment the neutron, neutron-lib and many of the decomposed projects are 
still failing with the v3. Does this mean that we are broken from the 11th?
For the decomposed projects we have a work around to help address this in the 
short term – need to increase timeout and need a flag from Zuul3 that is not 
part of Jenkins - 
https://github.com/openstack/vmware-nsx/blob/master/tools/tox_install_project.sh#L37
 (can we have ZUUL3_CLONER?)
Thanks
Gary

On 10/10/17, 2:59 AM, "Jeremy Stanley"  wrote:

The tl;dr is that we're planning to roll forward out of our partial
Zuul v3 rollback starting at 11:00 UTC on Wednesday October 11
(a little over 35 hours from now), so expect some CI downtime and
all of the benefits (though hopefully none of the drawbacks!) you
witnessed when we tried the first time.

It's been right at a week since we instituted a partial rollback of
our initial v3 roll-out. That week has been filled by diagnosing and
fixing all of the misbehaviors and performance degradation we
identified, including some new issues we discovered while running
under even heavier load and memory pressure artificially induced by
trying to fire check jobs for everything v2 was running but with
only a fraction of the node capacity. Numerous issues within the
translated legacy job configs were also fixed, and a bunch more of
them replaced by v3-native jobs.

We anticipate an outage for the CI system of somewhere between 30-60
minutes starting at 11:00 UTC on Wednesday October 11. Once
complete, we'll send a follow-up announcement along with a link to
where we're coordinating and triaging any newly observed issues. In
the meantime, if you've been digging into recent legacy job failures
for your projects you should consider trying to bring them to our
attention as soon as possible (in #openstack-infra on the Freenode
IRC network, or replying on-list to this announcement) and work on
fixing them if you're familiar enough with the failures to do so
yourself. We're assembling a sort of FAQ in the migration guide
here:

https://docs.openstack.org/infra/manual/zuulv3.html

...and we also have some more content in progress at:

https://etherpad.openstack.org/p/zuulv3-migration-faq

In summary, Zuul v3 is looking better than ever, and we hope you'll
be as pleased with it as we are!
-- 
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

Re: [openstack-dev] Security of Meta-Data

[Gary Kotton]

Hi,
You can configure the metadata service to be secure. You just need to make sure 
that nova is configured correctly. FYI - 
https://github.com/openstack/neutron/blob/master/neutron/conf/agent/metadata/config.py#L68
Thanks
Gary

On 10/4/17, 7:01 AM, "Joshua Harlow"  wrote:

I would treat the metadata service as not secure.

 From amazon docs (equivalent can be said about openstack):

'''
Important

Although you can only access instance metadata and user data from within 
the instance itself, the data is not protected by cryptographic methods. 
Anyone who can access the instance can view its metadata. Therefore, you 
should take suitable precautions to protect sensitive data (such as 
long-lived encryption keys). You should not store sensitive data, such 
as passwords, as user data.
'''


https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.aws.amazon.com_AWSEC2_latest_UserGuide_ec2-2Dinstance-2Dmetadata.html=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=6hYo6Fh9CLmjqptic1Jk22ZN3jgrnjOSs2p_8Opv7oo=XOsLXFFKlrL9E_B_lgNqvvqvTOKic_rIAJpQdVTMryg=
 

So private keys would be a no-no, public keys would be ok (since they 
are public anyway).

Giuseppe de Candia wrote:
> Hi Folks,
>
>
> Are there any documented conventions regarding the security model for
> MetaData?
>
>
> Note that CloudInit allows passing user and ssh service public/private
> keys via MetaData service (or ConfigDrive). One assumes it must be
> secure, but I have not found a security model or documentation.
>
>
> My understanding of the Neutron reference implementation is that
> MetaData requests are HTTP (not HTTPS) and go from the VM to the
> MetaData proxy on the Network Node (after which they are proxied to Nova
> meta-data API server). The path from VM to Network Node using HTTP
> cannot guarantee confidentiality and is also susceptible to
> Man-in-the-Middle attacks.
>
> Some Neutron drivers proxy Metadata requests locally from the node
> hosting the VM that makes the query. I have mostly seen this
> presented/motivated as a way of removing dependency on the Network node,
> but it should also increase security. Yet, I have not seen explicit
> discussions of the security model, nor any attempt to set a standard for
> security of the meta-data.
>
> Finally, there do not seem to be granular controls over what meta-data
> is presented over ConfigDrive (when enabled) vs. meta-data REST API. As
> an example, Nova vendor data is presented over both, if both are
> enabled; config drive is presumably more secure.
>
> thanks,
> Pino
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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


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

Re: [openstack-dev] [all] Update on Zuul v3 Migration - and what to do about issues

[Gary Kotton]

We have patches stuck for hours – only info is:
http://zuulv3.openstack.org/static/stream.html?uuid=128746a70c1843d7a94e887120ba381c=console.log
At the moment we are unable to do anything

On 10/3/17, 3:36 PM, "Boden Russell"  wrote:

On 10/3/17 5:17 AM, Sean Dague wrote:
> 
> Do we have a defined point on the calendar for getting the false
> negatives back below the noise threshold otherwise a rollback is
> implemented so that some of these issues can be addressed in parallel
> without holding up community development?

Along the same lines; where is the best place to get help with zuul v3
issues? The neutron-lib gate is on the floor with multiple problems; 2
broken gating jobs preventing patches from landing and all periodic jobs
broken preventing (safe) releases of neutron-lib. I've been adding the
issues to the etherpad [1] and trying to work through them solo, but
progress is very slow.


[1] https://etherpad.openstack.org/p/zuulv3-migration-faq

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


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

Re: [openstack-dev] [infra] pypi publishing

[Gary Kotton]

On 10/1/17, 9:40 PM, "Paul Belanger" <pabelan...@redhat.com> wrote:

On Sun, Oct 01, 2017 at 05:02:00AM -0700, Clark Boylan wrote:
> On Sat, Sep 30, 2017, at 10:28 PM, Gary Kotton wrote:
> > Hi,
> > Any idea why latest packages are not being published to pypi.
> > Examples are:
> > vmware-nsxlib 10.0.2 (latest stable/ocata)
> > vmware-nsxlib 11.0.1 (latest stable/pike)
> > vmware-nsxlib 11.1.0 (latest queens)
> > Did we miss a configuration that we needed to do in the infra projects?
> > Thanks
> > Gary
> 
> Looks like these are all new tags pushed within the last day. Looking at
> logs for 11.1.1 we see the tarball artifact creation failed [0] due to
> what is likely a bug in the new zuulv3 jobs.
> 
> [0]
> 
http://logs.openstack.org/e5/e5a2189276396201ad88a6c47360c90447c91589/release/publish-openstack-python-tarball/2bdd521/ara/result/6ec8ae45-7266-40a9-8fd5-3fb4abcde677/
> 
> We'll need to get the jobs debugged.
> 
This is broken because of: https://review.openstack.org/508563/

[Gary] Do we need to revert this? Once the issue is fixed how do we get the 
packages published?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [infra] Zull retry limit

[Gary Kotton]

Thanks!

On 10/1/17, 8:23 PM, "Clark Boylan" <cboy...@sapwetik.org> wrote:

On Sun, Oct 1, 2017, at 10:19 AM, Gary Kotton wrote:
> Hi,
> Is this an example of the solution that you are proposing -
> https://review.openstack.org/#/c/508775/. I also read that we should
> create a .zuul.yaml file. Not sure what the correct thing to do is.
> Please advise.
> Thanks
> Gary
> 

Yes 508775 is an example of what you should do. Adding a .zuul.yaml file
is something you can do but not necessary to correct this problem. You
would use a repo local .zuul.yaml file to add new jobs to your project.

Clark

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


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

Re: [openstack-dev] [infra] Zull retry limit

[Gary Kotton]

Hi,
Is this an example of the solution that you are proposing - 
https://review.openstack.org/#/c/508775/. I also read that we should create a 
.zuul.yaml file. Not sure what the correct thing to do is.
Please advise.
Thanks
Gary

On 10/1/17, 3:10 PM, "Clark Boylan" <cboy...@sapwetik.org> wrote:

On Sat, Sep 30, 2017, at 11:23 PM, Gary Kotton wrote:
> Hi,
> It seems like all patches are hitting this issue – “RETRY_LIMIT in 5m
> 35s”. Any idea? Is this specific to vmware-nsx or all projects?
> Did we miss doing an update for zuulv3?
>

This is specific to certain jobs. You can see general live status to
compare against global state at http://status.openstack.org/zuul. In
this particular case the job has attempted to provide a helpful error
message [0]. You should be able to create an openstack-tox-pep8 job
variant for vmware-nsx that includes neutron as a required project.
Documentation for how to go about that can be found at [1].

This does raise the question of why vmware-nsx needs to install neutron
to run pep8 though.

[0]

http://logs.openstack.org/30/508130/3/check/openstack-tox-pep8/7cb51cb/job-output.txt.gz#_2017-10-01_07_24_29_980352
[1] https://docs.openstack.org/infra/manual/zuulv3.html

Hope this helps,
Clark

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


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

[openstack-dev] [infra] Zull retry limit

[Gary Kotton]

Hi,
It seems like all patches are hitting this issue – “RETRY_LIMIT in 5m 35s”. Any 
idea? Is this specific to vmware-nsx or all projects?
Did we miss doing an update for zuulv3?
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

[openstack-dev] [infra] pypi publishing

[Gary Kotton]

Hi,
Any idea why latest packages are not being published to pypi.
Examples are:
vmware-nsxlib 10.0.2 (latest stable/ocata)
vmware-nsxlib 11.0.1 (latest stable/pike)
vmware-nsxlib 11.1.0 (latest queens)
Did we miss a configuration that we needed to do in the infra projects?
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

Re: [openstack-dev] Garbage patches for simple typo fixes

[Gary Kotton]

One thing that we could consider is adding ‘topy’ [i] to our gating. 

[i] https://pypi.python.org/pypi/topy

On 9/23/17, 2:47 AM, "Michael Johnson"  wrote:

A recent extreme example:

https://review.openstack.org/#/c/494981/1/specs/version0.8/active_passive_loadbalancer.rst

I would love to have a boilerplate statement I can use as a template
for things like this.  I feel bad -1/-2 these as I want to encourage
involvement, but they are a drain on the system.

Michael


On Fri, Sep 22, 2017 at 4:18 PM, Zhipeng Huang  
wrote:
> Hi Doug,
>
> Absolutely glad to help on this matter. We could take this offline first 
via
> email or irc chat and then comes up with a solution for the broader
> community to review
>
> On Sat, Sep 23, 2017 at 2:47 AM, Doug Hellmann 
> wrote:
>>
>> Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06
>> -0400:
>> > Doug,
>> > Howard (cc'ed) already did a bunch of reaching out especially on
>> > wechat. We should request his help.
>> >
>> > Howard,
>> > Can you please help with communications and follow up?
>> >
>> > Thanks,
>> > Dims
>>
>> Thanks, Dims and Howard,
>>
>> I think the problem has reached a point where it would be a good
>> idea to formalize our approach to outreach. We should track the
>> patches or patch series identified as problematic, so reviewers
>> know not to bother with them. We can also track who is contacting
>> whom (and how) so we don't have a bunch of people replicating work
>> or causing confusion for people who are trying to contribute. Having
>> that information will also help us figure out when we need to
>> escalate by finding the right managers to be talking to.
>>
>> Let's put together a small team to manage this instead of letting
>> it continue to cause frustration for everyone.
>>
>> Doug
>>
>> >
>> > On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann 
>> > wrote:
>> > > Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
>> > >> On 9/22/2017 7:10 AM, Tom Barron wrote:
>> > >> > FWIW I think it is better not to attribute motivation in these
>> > >> > cases.
>> > >> > Perhaps the code submitter is trying to pad stats, but perhaps 
they
>> > >> > are
>> > >> > just a new contributor trying to learn the process with a
>> > >> > "harmless"
>> > >> > patch, or just a compulsive clean-upper who hasn't thought through
>> > >> > the
>> > >> > costs in reviewer time and CI resources.
>> > >>
>> > >> I agree. However, the one that set me off last night was a person
>> > >> from
>> > >> one company who I've repeatedly -1ed the same types of patches in
>> > >> nova
>> > >> for weeks, including on stable branches, and within 10 minutes of
>> > >> each
>> > >> other across several repos, so it's clearly part of some daily
>> > >> routine.
>> > >> That's what prompted me to send something to the mailing list.
>> > >>
>> > >
>> > > As fungi points out, education and communication are likely to be
>> > > our best solution. Maybe one approach is to identify the companies
>> > > and individuals involved and find one of our community members to
>> > > contact them directly via email.  We would want the person doing
>> > > that to be willing to explain all of the reasons the community does
>> > > not want the sort of activity we are rejecting and to provide
>> > > guidance about more useful contributions (Matt's comment is a great
>> > > start on both). I imagine that conversation would take a good deal
>> > > of patience, especially after the second or third time, but a 
personal
>> > > touch frequently makes all the difference in these sorts of cases.
>> > >
>> > > If we have someone willing to step into that sort of role, I would
>> > > be happy to help craft the initial contact messages and advise as
>> > > needed.
>> > >
>> > > Does anyone want to volunteer to work with me and actually send the
>> > > emails?
>> > >
>> > > 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
>> >
>
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> 

Re: [Openstack] Hello

[Gary Kotton]

Hi,
I suggest that you take a look at https://wiki.openstack.org/wiki/Kuryr. This 
most probably already has the relevant watchers implemented.
Thanks
Gary

From: Mridu Bhatnagar 
Date: Sunday, September 10, 2017 at 1:40 PM
To: "openstack@lists.openstack.org" 
Subject: Re: [Openstack] Hello

Hi

I am Mridu. A B.tech computer science and engineering graduate. I looking 
forward to contributing in OpenStack in the coming outreachy. I am interested 
in topic

Add introspection HTTP REST points to the Kubernetes API watchers.
Required skills: Python
Optional skills: API design

Can someone please help me proceed. And how can I get in touch with the mentor.

Thanks
Mridu



On Fri, Sep 8, 2017 at 5:36 PM, Jeremy Stanley 
> wrote:
On 2017-09-08 11:06:51 +0530 (+0530), Raja Siddharth Raju wrote:
> My name is Raja Siddharth Raju, student of Computer Science Engineering
> specialization with Cyber Security Forensics under BTech Program 3rd Year.
> I wish to contribute to Open Stack Security and would love to be its team
> member. I am new to open stack but I have some knowledge about Cyber
> Security and web application vulnerabilities which interests me. As a
> beginner, what shall be my first steps to explore open cloud.

Welcome!

One other set of resources nobody seems to have mentioned yet: have
a look around https://security.openstack.org/ for our lists of
announced vulnerabilities, some of our security-oriented community
processes, and summaries of security-related software/tools under
development.
--
Jeremy Stanley

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : 
openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Hello

[Gary Kotton]

Hi,
I would suggest that you spin up a devstack instance - http://devstack.org/. 
Then you can start to find vulnerabilities ☺
Enjoy and welcome to OpenStack
Thanks
Gary

From: Raja Siddharth Raju 
Date: Friday, September 8, 2017 at 8:36 AM
To: "openstack@lists.openstack.org" 
Subject: [Openstack] Hello

Hi,
My name is Raja Siddharth Raju, student of Computer Science Engineering 
specialization with Cyber Security Forensics under BTech Program 3rd Year. I 
wish to contribute to Open Stack Security and would love to be its team member. 
I am new to open stack but I have some knowledge about Cyber Security and web 
application vulnerabilities which interests me. As a beginner, what shall be my 
first steps to explore open cloud.

--
Thanks and Regards,
Raja Siddharth Raju
(Mob:- 8178429427)
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?

[Gary Kotton]

On 9/4/17, 3:47 PM, "Stephen Finucane" <step...@that.guru> wrote:

On Mon, 2017-09-04 at 11:51 +0000, Gary Kotton wrote:
> On 9/4/17, 11:18 AM, "Stephen Finucane" <sfinu...@redhat.com> wrote:
> > Nova has a feature whereby it will provide instance host names that 
cloud-
> > init can extract and use inside the guest, i.e. this won't happen 
without
> > cloud-init. These host names are fully qualified domain names (FQDNs) 
based
> > upon the instance name and local domain name. However, as noted in bug
> > #1698010 [1], the domain name part of this is based up nova's 
'dhcp_domain'
> > option, which is a nova-network option that has been deprecated [2].
> > 
> > I've started work on a fix [3] that will allow us to retrieve this
> > information from neutron instead, uncoupling us from this legacy option.
> > However, some commentators have pointed out that this may not 
necessarily 
> > be what we want to do: a FQDN is a hostname and domain name, and using 
one 
> > as a hostname may not be that clever nor correct.
> >
> > My networking fu isn't strong enough to deliver a verdict so I'm hoping
> > someone else can make my mind up for me: do we want to migrate this 
feature
> > to neutron, or do we want to stop using FQDN and just use instance 
names?
>
> Hi,
>
> Your patch https://review.openstack.org/#/c/480616/ requires that neutron
> expose the ‘DNS Integration’ extension be support by neutron and the 
relevant
> networking plugin. If it does not then will be a regression and things 
will
> not work.
>
> In addition to this that is per network and not global so there will also 
be
> a regression for running instances if nova is updated.

OK, so ultimately this isn't something we can rely on from neutron?
[Gary] No, you can rely on it from Neutron – you just need to be aware that if 
the extension is supported then it can be used. If not then you should continue 
to use the existing configuration vaiable

 Does that
mean we should abandon the idea of providing FQDN when using neutron? Mores 
to
the original point, is there any reason we would want to/should use FQDN?

[Gary] Yes, we should support this. Applications make use of this and hence the 
support

Stephen

> > [1] https://bugs.launchpad.net/nova/+bug/1698010
> > [2] https://review.openstack.org/#/c/395683/
> > [3] https://review.openstack.org/#/c/480616/



__
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] Should we continue providing FQDNs for instance hostnames?

[Gary Kotton]

Hi,
Your patch https://review.openstack.org/#/c/480616/ requires that neutron 
expose the ‘DNS Integration’ extension be support by neutron and the relevant 
networking plugin. If it does not then will be a gression and things will not 
work.
In addition to this that is per network and not global so there will also be a 
regression for running instances if nova is updated.
Thanks
Gary


On 9/4/17, 11:18 AM, "Stephen Finucane"  wrote:

Nova has a feature whereby it will provide instance host names that 
cloud-init
can extract and use inside the guest, i.e. this won't happen without cloud-
init. These host names are fully qualified domain names (FQDNs) based upon 
the
instance name and local domain name. However, as noted in bug #1698010 [1], 
the
domain name part of this is based up nova's 'dhcp_domain' option, which is a
nova-network option that has been deprecated [2].

I've started work on a fix [3] that will allow us to retrieve this 
information
from neutron instead, uncoupling us from this legacy option. However, some
commentators have pointed out that this may not necessarily be what we want 
to
do: a FQDN is a hostname and domain name, and using one as a hostname may 
not
be that clever nor correct.

My networking fu isn't strong enough to deliver a verdict so I'm hoping 
someone
else can make my mind up for me: do we want to migrate this feature to 
neutron,
or do we want to stop using FQDN and just use instance names?

Cheers,
Stephen

[1] https://bugs.launchpad.net/nova/+bug/1698010
[2] https://review.openstack.org/#/c/395683/
[3] https://review.openstack.org/#/c/480616/

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


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

Re: [openstack-dev] [neutron][networking-l2gw] pike

[Gary Kotton]

Hi,
I will do this.
Thanks
Gary

On 8/8/17, 4:47 AM, "Takashi Yamamoto"  wrote:

hi,

who is planning to make stable/pike for networking-l2gw?

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


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

Re: [openstack-dev] [TripleO] Error when running quickstart.sh

[Gary Kotton]

Sorry, my bad, when setting the guest to have vmkernel6Guest it works.

From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Sunday, August 6, 2017 at 6:40 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [TripleO] Error when running quickstart.sh

Hi,
When I do this on a virtual host I get the following error:

Sunday 06 August 2017  08:22:04 -0700 (0:00:02.641)   0:06:45.482 *
failed: [127.0.0.2] (item={u'flavor': u'control', u'virtualbmc_port': 6230, 
u'name': u'control_0'}) => {"failed": true, "item": {"flavor": "control", 
"name": "control_0", "virtualbmc_port": 6230}, "msg": "invalid argument: could 
not find capabilities for arch=x86_64 domaintype=kvm "}
failed: [127.0.0.2] (item={u'flavor': u'compute', u'virtualbmc_port': 6231, 
u'name': u'compute_0'}) => {"failed": true, "item": {"flavor": "compute", 
"name": "compute_0", "virtualbmc_port": 6231}, "msg": "invalid argument: could 
not find capabilities for arch=x86_64 domaintype=kvm "}

Any suggestions on how I can work around this? Virsh capabilities are below [i]
Thanks
Gary

[i]
[root@centos ~]# virsh --connect qemu:///system capabilities


  
d5203442-743d-de37-8ade-7d7dc3e1971d

  x86_64
  Haswell-noTSX
  Intel
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  
  


  
  
tcp
rdma
  


  

  16776696
  4194174
  0
  0
  

  
  








  

  


  selinux
  0
  system_u:system_r:svirt_t:s0
  system_u:system_r:svirt_tcg_t:s0


  dac
  0
  +107:+107
  +107:+107

  

  
hvm

  32
  /usr/libexec/qemu-kvm
  pc-i440fx-rhel7.0.0
  pc
  rhel6.0.0
  rhel6.1.0
  rhel6.2.0
  rhel6.3.0
  rhel6.4.0
  rhel6.5.0
  rhel6.6.0
  


  
  
  
  
  
  
  

  

  
hvm

  64
  /usr/libexec/qemu-kvm
  pc-i440fx-rhel7.0.0
  pc
  rhel6.0.0
  rhel6.1.0
  rhel6.2.0
  rhel6.3.0
  rhel6.4.0
  rhel6.5.0
  rhel6.6.0
  


  
  
  
  
  

  



__
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] [TripleO] Error when running quickstart.sh

[Gary Kotton]

Hi,
When I do this on a virtual host I get the following error:

Sunday 06 August 2017  08:22:04 -0700 (0:00:02.641)   0:06:45.482 *
failed: [127.0.0.2] (item={u'flavor': u'control', u'virtualbmc_port': 6230, 
u'name': u'control_0'}) => {"failed": true, "item": {"flavor": "control", 
"name": "control_0", "virtualbmc_port": 6230}, "msg": "invalid argument: could 
not find capabilities for arch=x86_64 domaintype=kvm "}
failed: [127.0.0.2] (item={u'flavor': u'compute', u'virtualbmc_port': 6231, 
u'name': u'compute_0'}) => {"failed": true, "item": {"flavor": "compute", 
"name": "compute_0", "virtualbmc_port": 6231}, "msg": "invalid argument: could 
not find capabilities for arch=x86_64 domaintype=kvm "}

Any suggestions on how I can work around this? Virsh capabilities are below [i]
Thanks
Gary

[i]
[root@centos ~]# virsh --connect qemu:///system capabilities


  
d5203442-743d-de37-8ade-7d7dc3e1971d

  x86_64
  Haswell-noTSX
  Intel
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  


  
  
  


  
  
tcp
rdma
  


  

  16776696
  4194174
  0
  0
  

  
  








  

  


  selinux
  0
  system_u:system_r:svirt_t:s0
  system_u:system_r:svirt_tcg_t:s0


  dac
  0
  +107:+107
  +107:+107

  

  
hvm

  32
  /usr/libexec/qemu-kvm
  pc-i440fx-rhel7.0.0
  pc
  rhel6.0.0
  rhel6.1.0
  rhel6.2.0
  rhel6.3.0
  rhel6.4.0
  rhel6.5.0
  rhel6.6.0
  


  
  
  
  
  
  
  

  

  
hvm

  64
  /usr/libexec/qemu-kvm
  pc-i440fx-rhel7.0.0
  pc
  rhel6.0.0
  rhel6.1.0
  rhel6.2.0
  rhel6.3.0
  rhel6.4.0
  rhel6.5.0
  rhel6.6.0
  


  
  
  
  
  

  



__
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] Cleaning up inactive meetbot channels

[Gary Kotton]

FYI - https://review.openstack.org/486887
We should be using #openstack-neutron instead. 

On 7/20/17, 8:46 PM, "Graham Hayes"  wrote:

On 19/07/17 20:24, Jeremy Stanley wrote:
> For those who are unaware, Freenode doesn't allow any one user to
> /join more than 120 channels concurrently. This has become a
> challenge for some of the community's IRC bots in the past year,
> most recently the "openstack" meetbot (which not only handles
> meetings but also takes care of channel logging to
> eavesdrop.openstack.org and does the nifty bug number resolution
> some people seem to like).
> 
> I have run some rudimentary analysis and come up with the following
> list of channels which have had fewer than 10 lines said by anyone
> besides a bot over the past three months:
> 
> #craton
> #openstack-api
> #openstack-app-catalog
> #openstack-bareon
> #openstack-cloudpulse
> #openstack-community
> #openstack-cue
> #openstack-diversity
> #openstack-gluon
> #openstack-gslb

This should have been gone a while ago

https://review.openstack.org/#/q/topic:remove-openstack-gslb-irc

> #openstack-ko
> #openstack-kubernetes
> #openstack-networking-cisco
> #openstack-neutron-release
> #openstack-opw
> #openstack-pkg
> #openstack-product
> #openstack-python3
> #openstack-quota
> #openstack-rating
> #openstack-solar
> #openstack-swauth
> #openstack-ux
> #openstack-vmware-nsx
> #openstack-zephyr
> 
> I have a feeling many of these are either no longer needed, or what
> little and infrequent conversation they get used for could just as
> easily happen in a general channel like #openstack-dev or #openstack
> or maybe in the more active channel of their parent team for some
> subteams. Who would miss these if we ceased logging/using them? Does
> anyone want to help by asking around to people who might not see
> this thread, maybe by popping into those channels and seeing if any
> of the sleeping denizens awaken and say they still want to keep it
> around?
> 
> Ultimately we should improve our meetbot deployment to support
> sharding channels across multiple bots, but that will take some time
> to implement and needs volunteers willing to work on it. In the
> meantime we're running with the meetbot present in 120 channels and
> have at least one new channel that desires logging and can't get it
> until we whittle that number down.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



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

[openstack-dev] [neutron][l2-gateway] Added Ricardo Noriega to the core team

[Gary Kotton]

Hi,
Over the last few months Ricardo Noriega has been making many contributions to 
the project and has actually helped get it to the stage where it’s a lot 
healthier than before ☺. I am adding him to the core team.
Congratulations!
A luta continua
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

Re: [Openstack] Looking for a case study

[Gary Kotton]

Hi,
As part of trying to help people use OpenStack I encouraged a friend of mine 
who was teaching a course at a University to have all of his students do their 
projects on OpenStack instances. Prior to each lab he would prep a snapshot of 
the instance and then the students would continue from them. It was a great 
success.
Each student was a tenant and had their own isolated networks etc. It was fun 
and in the end a very successful endeavor.
Thanks
Gary

From: Rahil Gandotra 
Reply-To: "rahil.gando...@colorado.edu" 
Date: Wednesday, July 19, 2017 at 4:47 AM
To: Irum Rauf , "openstack@lists.openstack.org" 

Subject: Re: [Openstack] Looking for a case study

How about implementing a campus lab network for students?
You could use multiple servers to spin up controller, compute and network. And 
then segregate userspace for each student which would use Keystone for 
authorization. Additionally you could maintain a state of the quotas allocated 
to each student.

- Rahil



On Tue, Jul 18, 2017 at 3:34 PM, Irum Rauf 
> wrote:

Hello all,
I am a researcher and I am looking for a case study with OpenStack. I have 
installed open stack with DevStack and have played with it already. Now, I am 
looking for a real world case study with openstack to apply my approach on but 
I am not able to. I am looking for:

- A case study developed with open stack that I can invoke via its API through 
curl.

- The case study should involve KeyStone for authentication and authorisation 
of its resources

- The case study should be stateful.

Any clues in this regard would be very helpful.

Many Thanks.


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : 
openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



--
Rahil Gandotra
Graduate Student
Interdisciplinary Telecom Program
University of Colorado Boulder
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [infra] Gerrit slow

[Gary Kotton]

Hi,
Gerrit is very slow at the moment. Is anyone else hitting this issue?
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

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[Gary Kotton]

Hi,
Will this also be moving to eol - 
https://github.com/openstack/requirements/blob/stable/mitaka/global-requirements.txt?
Thanks
Gary

On 7/10/17, 9:23 AM, "Andreas Jaeger"  wrote:

On 2017-07-07 17:37, Doug Szumski wrote:
> 
>> On 2017-07-05 12:13, Joshua Hesketh wrote:
>>> Hi all,
>>>
>>> Very sorry for the delay on processing this request. I have now EOL'd 
>>> stable/mitaka branches for projects listed in [1].
>>>
>>> If there are any mistakes it should be possible to restore the branch 
>>> at the correct position. Similarly please let me know if there were 
>>> any projects that should have been EOL'd but missed out.
> 
> Please also remove stable/mitaka from bareon-ironic

OK, added. I'm waiting for packstack confirmation.

The current list is now:


openstack/sahara-extra   stable/icehousePlease retire
openstack/sahara-extra   stable/mitaka  Please retire
openstack/packstack  stable/kiloWaiting for confirmation
openstack/packstack  stable/liberty Waiting for confirmation
openstack/packstack  stable/mitaka  Waiting for confirmation
openstack/bareon-ironic  stable/mitaka  Please retire

openstack/rpm-packaging  stable/mitaka  Please retire
openstack/training-labs  stable/mitaka  Please retire

Not done in

https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.githubusercontent.com_tbreeds_c99e62bf8da19380e4eb130be8783be7_raw_6d02deb40e07516ce8fc529d2ba8c74af11a5a6b_mitaka-5Feol-5Fdata.txt=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=8JDeI5-ToCWlT4wlMOEK26WybSrP1mfZXQUx_wH4Yvo=y5Ib3yOnStYUMsnSZ62_ZUm0zbcLuqrk34Hfk1mVORA=
 

openstack/astara stable/mitaka  Please retire


Special treatment:
openstack/training-labs icehouse-eol (just delete branch, tag exists)
openstack/training-labs juno-eol (delete branch, create tag instead)


Any other late comers?

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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


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

Re: [openstack-dev] [Nova][Neutron] Allow passing security groups when attaching interfaces?

[Gary Kotton]

Hi,
When you attach an interface there are a number of options:
1. Pass a existing port
2. Pass a network
In the second case a new port will be created and by default that will have the 
default security group.
You could try the first option by attaching the security group to the port
Thanks
Gary

From: Zhenyu Zheng 
Reply-To: OpenStack List 
Date: Thursday, July 6, 2017 at 12:45 PM
To: OpenStack List 
Subject: [openstack-dev] [Nova][Neutron] Allow passing security groups when 
attaching interfaces?

Hi,

Our product has meet this kind of problem, when we boot instances, we are 
allowed to pass security groups, and if we provided network id, ports with the 
sg we passed will be created and when we show instances, we can see security 
groups field of instance is the sg we provided. But when we attach again some 
new interfaces(using network_id), the newly added interfaces will be in the 
default security group.

We are wondering, will it be better to allow passing security groups when 
attaching interfaces? or it is considered to be a proxy-api which we do not 
like?

BR,

Kevin Zheng
__
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] tempest failures when deploying neutron-server in wsgi with apache

[Gary Kotton]

+1

From: Kevin Benton 
Reply-To: OpenStack List 
Date: Monday, June 19, 2017 at 10:33 AM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] tempest failures when deploying 
neutron-server in wsgi with apache

Thanks. Maybe this would be a good opportunity to just have people start 
putting everything in neutron.conf if they want to switch to wsgi.

On Mon, Jun 19, 2017 at 12:21 AM, Matthew Treinish 
> wrote:
On Mon, Jun 19, 2017 at 12:09:12AM -0700, Kevin Benton wrote:
> I've been working on Victor's patch a bit. One thing that isn't clear to me
> is how we can get the neutron.conf options loaded when using WSGI. How are
> other projects doing this?

Most projects are using a default location, for example:

https://review.openstack.org/#/c/459450/11/glance/common/wsgi_app.py

Which IIRC I just looked at how other project's wsgi entrypoints were doing it
when I wrote that. The issue I think we'll hit with Neutron is that by default
we tell everyone to do that annoying multi-file config setup, which makes doing
a default like this difficult. Personally I think we need to change that,
because it's not needed and makes it generally confusing, but even if we did
it wouldn't solve the upgrade path from non-wsgi to wsgi.

-Matt Treinish

>
> On Fri, Jun 2, 2017 at 7:44 AM, Emilien Macchi 
> > wrote:
>
> > On Thu, Jun 1, 2017 at 10:28 PM, Morales, Victor
> > > wrote:
> > > Hi Emilien,
> > >
> > > I noticed that the configuration file was created using puppet.  I
> > submitted a patch[1] that was targeting to include the changes in Devstack.
> > My major concern is with the value of WSGIScriptAlias which should be
> > pointing to WSGI script.
> >
> > Thanks for looking, the script that is used is from
> > /usr/bin/neutron-api which is I think correct. If you look at logs,
> > you can see that API actually works but some tempest tests fail
> > though...
> >
> > > Regards/Saludos
> > > Victor Morales
> > >
> > > [1] https://review.openstack.org/#/c/439191
> > >
> > > On 5/31/17, 4:40 AM, "Emilien Macchi" 
> > > > wrote:
> > >
> > > Hey folks,
> > >
> > > I've been playing with deploying Neutron in WSGI with Apache and
> > > Tempest tests fail on spawning Nova server when creating Neutron
> > > ports:
> > > http://logs.openstack.org/89/459489/4/check/gate-puppet-
> > openstack-integration-4-scenario001-tempest-centos-7/
> > f2ee8bf/console.html#_2017-05-30_13_09_22_715400
> > >
> > > I haven't found anything useful in neutron-server logs:
> > > http://logs.openstack.org/89/459489/4/check/gate-puppet-
> > openstack-integration-4-scenario001-tempest-centos-7/
> > f2ee8bf/logs/apache/neutron_wsgi_access_ssl.txt.gz
> > >
> > > Before I file a bug in neutron, can anyone look at the logs with me
> > > and see if I missed something in the config:
> > > http://logs.openstack.org/89/459489/4/check/gate-puppet-
> > openstack-integration-4-scenario001-tempest-centos-7/
> > f2ee8bf/logs/apache_config/10-neutron_wsgi.conf.txt.gz
> > >
> > > Thanks for the help,
> > > --
> > > Emilien Macchi
> > >
> > > 
> > __
> > > 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
> >
> >
> >
> > --
> > Emilien Macchi
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

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

Re: [openstack-dev] [neutron] security group OVO change

[Gary Kotton]

Sorry for being vague – have been debugging.
We overwrite the base method:

with db_api.context_manager.writer.using(context):
secgroup_db = (
super(NsxV3Plugin, self).create_security_group(
context, security_group, default_sg))
nsx_db.save_sg_mappings(context,
secgroup_db['id'],
ns_group['id'],
firewall_section['id'])
self._process_security_group_properties_create(context,
   secgroup_db,
   secgroup,
   default_sg)

The secgroup_db that returns always has empty rules. If I remove the 
transaction then it works.
Still trying to figure out why when we call:
with db_api.context_manager.writer.using(context):
secgroup_db = (
super(NsxV3Plugin, self).create_security_group(…

The rules are not populated. The db_api.context_manager.writer.using is what is 
causing the problem.

As a work around we reread the object when we need to process the rules. Not 
sure if anyone else has hit this
Thanks
Gary

From: Kevin Benton <ke...@benton.pub>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, June 19, 2017 at 10:01 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Cc: "isaku.yamah...@gmail.com" <isaku.yamah...@gmail.com>
Subject: Re: [openstack-dev] [neutron] security group OVO change

Do you mean the callback event for AFTER_CREATE is missing the rules when it's 
for default security groups?

On Sun, Jun 18, 2017 at 4:44 AM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
That patch looks good. We still have an issue in that the create security 
groups does not return the list of the default rules.
Thanks
Gary

On 6/17/17, 2:33 AM, "Isaku Yamahata" 
<isaku.yamah...@gmail.com<mailto:isaku.yamah...@gmail.com>> wrote:

It also broke networking-odl.
The patch[1] is needed to unbreak.
[1] https://review.openstack.org/#/c/448420/

necessary db info is taken from context.session.new.
But with OVO, those expunge themselves with create method.
Those info needs to be passed as callback argument.

Thanks,

On Fri, Jun 16, 2017 at 01:25:28PM -0700,
Ihar Hrachyshka <ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:

> To close the loop here,
>
> - this also broke heat py3 job (https://launchpad.net/bugs/1698355)
> - we polished https://review.openstack.org/474575 to fix both
> vmware-nsx and heat issues
> - I also posted a patch for oslo.serialization for the bug that
> triggered MemoryError in heat gate:
> https://review.openstack.org/475052
> - the vmware-nsx adoption patch is at:
> https://review.openstack.org/#/c/474608/ and @boden is working on it,
> should be ready to go in due course.
    >
> Thanks and sorry for inconveniences,
> Ihar
>
> On Thu, Jun 15, 2017 at 6:17 AM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
> > Hi,
> >
> > The commit https://review.openstack.org/284738 has broken decomposed 
plugins
> > (those that extend security groups and rules). The reason for this is 
that
> > there is a extend callback that we use which expects to get a database
> > object and the aforementioned patch passes a new neutron object.
> >
> > I have posted [i] to temporarily address the issue. An alternative is to
> > revert the patch until the decomposed plugins can figure out how to
> > correctly address this.
> >
> > Thanks
> >
> > Gary
> >
> > [i] https://review.openstack.org/474575
> >
> >
> > 
__
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>

Re: [Openstack] Routed provider networks

[Gary Kotton]

Hi,
Is there any trace? That will help troubleshoot.
Thanks
gary

From: Alex Evonosky <alex.evono...@gmail.com>
Date: Sunday, June 18, 2017 at 5:27 PM
To: Gary Kotton <gkot...@vmware.com>
Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org>
Subject: Re: [Openstack] Routed provider networks

Gary-

Thank you for the feedback.  I issued the command while tailing the log:

2017-06-18 10:24:51.841 12018 INFO neutron.api.v2.resource 
[req-da8fa8be-1cae-4b5e-a1cf-2206a284476a 7e7176b79f94483c8b802a7004466e66 
664dc5e6023140eca0faeb2d0ecc31c2 - - -] create failed (client error): The 
server could not comply with the request since it is either malformed or 
otherwise incorrect.
2017-06-18 10:24:51.843 12018 INFO neutron.wsgi 
[req-da8fa8be-1cae-4b5e-a1cf-2206a284476a 7e7176b79f94483c8b802a7004466e66 
664dc5e6023140eca0faeb2d0ecc31c2 -


As for the ocata config, this was built by using the ocata:

https://docs.openstack.org/ocata/install-guide-ubuntu/


Thank you.




On Sun, Jun 18, 2017 at 10:17 AM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
Please look in /var/log/neutron/neutron-server.log
That should provide and exception trace
Thanks
Gary

From: Alex Evonosky <alex.evono...@gmail.com<mailto:alex.evono...@gmail.com>>
Date: Sunday, June 18, 2017 at 5:04 PM
To: "openstack@lists.openstack.org<mailto:openstack@lists.openstack.org>" 
<openstack@lists.openstack.org<mailto:openstack@lists.openstack.org>>
Subject: [Openstack] Routed provider networks

Hello-

I wanted to test the routed provider networks of Ocata, and following the 
example config:

https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html

I typed in the following on my controller node:


@openstack-controller1:~# openstack network create --share 
--provider-physical-network provider1 --provider-network-type vlan 
--provider-segment 2016 multisegment1

and I receive this:

Error while executing command: Bad Request


Is there a log that may show what this error is referring to?


Thank you.


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [neutron] security group OVO change

[Gary Kotton]

Hi,
That patch looks good. We still have an issue in that the create security 
groups does not return the list of the default rules.
Thanks
Gary

On 6/17/17, 2:33 AM, "Isaku Yamahata" <isaku.yamah...@gmail.com> wrote:

It also broke networking-odl.
The patch[1] is needed to unbreak.
[1] https://review.openstack.org/#/c/448420/

necessary db info is taken from context.session.new.
But with OVO, those expunge themselves with create method.
Those info needs to be passed as callback argument.

Thanks,

On Fri, Jun 16, 2017 at 01:25:28PM -0700,
Ihar Hrachyshka <ihrac...@redhat.com> wrote:

> To close the loop here,
> 
> - this also broke heat py3 job (https://launchpad.net/bugs/1698355)
> - we polished https://review.openstack.org/474575 to fix both
> vmware-nsx and heat issues
> - I also posted a patch for oslo.serialization for the bug that
> triggered MemoryError in heat gate:
> https://review.openstack.org/475052
> - the vmware-nsx adoption patch is at:
> https://review.openstack.org/#/c/474608/ and @boden is working on it,
> should be ready to go in due course.
> 
> Thanks and sorry for inconveniences,
    > Ihar
> 
> On Thu, Jun 15, 2017 at 6:17 AM, Gary Kotton <gkot...@vmware.com> wrote:
> > Hi,
> >
> > The commit https://review.openstack.org/284738 has broken decomposed 
plugins
> > (those that extend security groups and rules). The reason for this is 
that
> > there is a extend callback that we use which expects to get a database
> > object and the aforementioned patch passes a new neutron object.
> >
> > I have posted [i] to temporarily address the issue. An alternative is to
> > revert the patch until the decomposed plugins can figure out how to
> > correctly address this.
> >
> > Thanks
> >
> > Gary
> >
> > [i] https://review.openstack.org/474575
> >
> >
> > 
__
> > 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

-- 
Isaku Yamahata <isaku.yamah...@gmail.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

[openstack-dev] [neutron] security group OVO change

[Gary Kotton]

Hi,
The commit https://review.openstack.org/284738 has broken decomposed plugins 
(those that extend security groups and rules). The reason for this is that 
there is a extend callback that we use which expects to get a database object 
and the aforementioned patch passes a new neutron object.
I have posted [i] to temporarily address the issue. An alternative is to revert 
the patch until the decomposed plugins can figure out how to correctly address 
this.
Thanks
Gary
[i] https://review.openstack.org/474575
__
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 breakage

[Gary Kotton]

Hi,
That patch will now need to be tweaked so that we can enable the requirements 
to be bumped. Gate is back to usual after the requirements were reverted.
Thanks
Gary

On 6/7/17, 9:40 PM, "Ihar Hrachyshka" <ihrac...@redhat.com> wrote:

UPD: in case you wonder if that's fixed, we are waiting for 
https://review.openstack.org/#/c/471763/ to land.

Ihar


On 06/07/2017 05:23 AM, Akihiro Motoki wrote:
> Six 1.10.0 is not the root cause. The root cause is the version bump
> of pylint (and astroid).
> Regarding pylint and astroid, I think the issue will go once
> https://review.openstack.org/#/c/469491/ is merged.
> However, even after the global requirement is merged, neutron pylint will 
fail
> because pylint 1.7.1 has a bit different syntax check compared to pylint 
1.4.3.
>
> I wonder pylint version bump should be announced because it
> potentially breaks individual project gate.
>
> Is it better to revert pylint version bump in global-requirements, or
> just to ignore some pylint rules temporarily in neutron?
>
> Akihiro
>
>
> 2017-06-07 20:43 GMT+09:00 Gary Kotton <gkot...@vmware.com>:
>> Hi,
>>
>> Please see bug https://bugs.launchpad.net/neutron/+bug/1696403. Seems 
like
>> six 1.10.0 has broken us.
>>
>> I have posted a patch in the requirements project. Not 100% sure that 
this
>> is the right way to go. At least that will enable us to address this in
>> neutron.
>>
>> 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
>>
> __
> 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-dev] [neutron] pep8 breakage

[Gary Kotton]

Hi,
Please see bug https://bugs.launchpad.net/neutron/+bug/1696403. Seems like six 
1.10.0 has broken us.
I have posted a patch in the requirements project. Not 100% sure that this is 
the right way to go. At least that will enable us to address this in neutron.
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

Re: [openstack-dev] [neutron] pep8 broken

[Gary Kotton]

Hi,
More details:

The urllib<https://docs.python.org/2/library/urllib.html#module-urllib>, 
urllib2<https://docs.python.org/2/library/urllib2.html#module-urllib2>, and 
urlparse<https://docs.python.org/2/library/urlparse.html#module-urlparse> 
modules have been combined in the 
urllib<https://docs.python.org/3/library/urllib.html#module-urllib> package in 
Python 3. The six.moves.urllib package is a version-independent location for 
this functionality; its structure mimics the structure of the Python 3 
urllib<https://docs.python.org/3/library/urllib.html#module-urllib> package.

Thanks and sorry for the spam
Gary

From: Gary Kotton <gkot...@vmware.com>
Date: Wednesday, June 7, 2017 at 2:03 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] pep8 broken

Sorry my bad.
The problem is that our requirements use six and in 1.10 files are missing


From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Wednesday, June 7, 2017 at 1:00 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] pep8 broken

Seems like the whole world is broken now:

2017-06-07 
09:56:23.336255<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_56_23_336255>
 | pep8 runtests: PYTHONHASHSEED='681905263'
2017-06-07 
09:56:23.336291<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_56_23_336291>
 | pep8 runtests: commands[0] | sh ./tools/misc-sanity-checks.sh
2017-06-07 
09:56:23.338319<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_56_23_338319>
 |   /home/jenkins/workspace/gate-vmware-nsx-pep8-ubuntu-xenial$ /bin/sh 
./tools/misc-sanity-checks.sh
2017-06-07 
09:56:26.180998<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_56_26_180998>
 | pep8 runtests: commands[1] | flake8
2017-06-07 
09:56:26.183583<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_56_26_183583>
 |   /home/jenkins/workspace/gate-vmware-nsx-pep8-ubuntu-xenial$ 
/home/jenkins/workspace/gate-vmware-nsx-pep8-ubuntu-xenial/.tox/pep8/bin/flake8
2017-06-07 
09:57:02.335638<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_335638>
 | pep8 runtests: commands[2] | sh ./tools/coding-checks.sh --pylint
2017-06-07 
09:57:02.338619<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_338619>
 |   /home/jenkins/workspace/gate-vmware-nsx-pep8-ubuntu-xenial$ /bin/sh 
./tools/coding-checks.sh --pylint
2017-06-07 
09:57:02.339139<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_339139>
 | Running pylint...
2017-06-07 
09:57:02.339210<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_339210>
 | You can speed this up by running it on 'HEAD~[0-9]' (e.g. HEAD~1, this 
change only)...
2017-06-07 
09:57:02.966716<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_966716>
 | Problem importing module classes.pyc: cannot import name InferenceContext
2017-06-07 
09:57:02.982457<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_982457>
 | Problem importing module classes.py: cannot import name InferenceContext
2017-06-07 
09:57:03.398914<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_398914>
 | [7;33m* Module vmware_nsx.nsx_cluster[0m
2017-06-07 
09:57:03.399073<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399073>
 | [1;31mE[0m: 45, 8: [1;31mUndefined variable 'self'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399152<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399152>
 | [1;31mE[0m: 46, 8: [1;31mUndefined variable 'self'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399222<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399222>
 | [1;31mE[0m: 47, 8: [1;31mUndefined variable 'self'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399267<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.h

Re: [openstack-dev] [neutron] pep8 broken

[Gary Kotton]

Sorry my bad.
The problem is that our requirements use six and in 1.10 files are missing


From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Wednesday, June 7, 2017 at 1:00 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] pep8 broken

Seems like the whole world is broken now:

2017-06-07 
09:56:23.336255<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_56_23_336255>
 | pep8 runtests: PYTHONHASHSEED='681905263'
2017-06-07 
09:56:23.336291<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_56_23_336291>
 | pep8 runtests: commands[0] | sh ./tools/misc-sanity-checks.sh
2017-06-07 
09:56:23.338319<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_56_23_338319>
 |   /home/jenkins/workspace/gate-vmware-nsx-pep8-ubuntu-xenial$ /bin/sh 
./tools/misc-sanity-checks.sh
2017-06-07 
09:56:26.180998<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_56_26_180998>
 | pep8 runtests: commands[1] | flake8
2017-06-07 
09:56:26.183583<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_56_26_183583>
 |   /home/jenkins/workspace/gate-vmware-nsx-pep8-ubuntu-xenial$ 
/home/jenkins/workspace/gate-vmware-nsx-pep8-ubuntu-xenial/.tox/pep8/bin/flake8
2017-06-07 
09:57:02.335638<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_335638>
 | pep8 runtests: commands[2] | sh ./tools/coding-checks.sh --pylint
2017-06-07 
09:57:02.338619<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_338619>
 |   /home/jenkins/workspace/gate-vmware-nsx-pep8-ubuntu-xenial$ /bin/sh 
./tools/coding-checks.sh --pylint
2017-06-07 
09:57:02.339139<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_339139>
 | Running pylint...
2017-06-07 
09:57:02.339210<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_339210>
 | You can speed this up by running it on 'HEAD~[0-9]' (e.g. HEAD~1, this 
change only)...
2017-06-07 
09:57:02.966716<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_966716>
 | Problem importing module classes.pyc: cannot import name InferenceContext
2017-06-07 
09:57:02.982457<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_02_982457>
 | Problem importing module classes.py: cannot import name InferenceContext
2017-06-07 
09:57:03.398914<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_398914>
 | [7;33m* Module vmware_nsx.nsx_cluster[0m
2017-06-07 
09:57:03.399073<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399073>
 | [1;31mE[0m: 45, 8: [1;31mUndefined variable 'self'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399152<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399152>
 | [1;31mE[0m: 46, 8: [1;31mUndefined variable 'self'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399222<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399222>
 | [1;31mE[0m: 47, 8: [1;31mUndefined variable 'self'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399267<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399267>
 | [1;31mE[0m: 48, 8: [1;31mUndefined variable 'self'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399308<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399308>
 | [1;31mE[0m: 48,27: [1;31mUndefined variable 'kwargs'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399348<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399348>
 | [1;31mE[0m: 50,38: [1;31mUndefined variable 'self'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399385<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399385>
 | [1;31mE[0m: 53,46: [1;31mUndefined variable 'opt'[0m 
([1;31mundef

Re: [openstack-dev] [neutron] pep8 broken

[Gary Kotton]

ep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399482>
 | [1;31mE[0m: 54,54: [1;31mUndefined variable 'opt'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399547<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399547>
 | [1;31mE[0m: 55,15: [1;31mUndefined variable 'depr_func'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399617<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399617>
 | [1;31mE[0m: 56,16: [1;31mUndefined variable 'depr_func'[0m 
([1;31mundefined-variable[0m)
2017-06-07 
09:57:03.399683<http://logs.openstack.org/66/471666/2/check/gate-vmware-nsx-pep8-ubuntu-xenial/b1bc4df/console.html#_2017-06-07_09_57_03_399683>
 | [1;31mE[0m: 56,26: [1;31mUndefined variable 'val'[0m 
([1;31mundefined-variable[0m)



From: Gary Kotton <gkot...@vmware.com>
Date: Wednesday, June 7, 2017 at 12:05 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] pep8 broken

Thanks!

Maybe this is the source of the failures that we are seeing now and we need to 
address that in the decomposed projects.

From: Kevin Benton <ke...@benton.pub>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Wednesday, June 7, 2017 at 11:59 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] pep8 broken

I think this was meant to fix it. https://review.openstack.org/#/c/471512/

On Wed, Jun 7, 2017 at 4:51 AM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
It seems that the pep8 is broken due to 
https://github.com/openstack/requirements/commit/99fae827973465147359cc7032c83003802612a7<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_requirements_commit_99fae827973465147359cc7032c83003802612a7=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=-4ErU2yIKEhsHlidjK8bsYqNHbBNes1m53GBtaagckE=03DfTv37JtfBJjCw02wzp8Up2hucSiIJLxGSWawTZJI=>
Should we revert this?
Thanks
Gary

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

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

Re: [openstack-dev] [neutron] pep8 broken

[Gary Kotton]

Thanks!

Maybe this is the source of the failures that we are seeing now and we need to 
address that in the decomposed projects.

From: Kevin Benton <ke...@benton.pub>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Wednesday, June 7, 2017 at 11:59 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] pep8 broken

I think this was meant to fix it. https://review.openstack.org/#/c/471512/

On Wed, Jun 7, 2017 at 4:51 AM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
It seems that the pep8 is broken due to 
https://github.com/openstack/requirements/commit/99fae827973465147359cc7032c83003802612a7<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_requirements_commit_99fae827973465147359cc7032c83003802612a7=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=-4ErU2yIKEhsHlidjK8bsYqNHbBNes1m53GBtaagckE=03DfTv37JtfBJjCw02wzp8Up2hucSiIJLxGSWawTZJI=>
Should we revert this?
Thanks
Gary

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

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

[openstack-dev] [neutron] pep8 broken

[Gary Kotton]

Hi,
It seems that the pep8 is broken due to 
https://github.com/openstack/requirements/commit/99fae827973465147359cc7032c83003802612a7
Should we revert this?
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

Re: [openstack-dev] [infra] Update for global requirements

[Gary Kotton]

Thanks!
It seems like https://review.openstack.org/440882 is the problem. Now that we 
have resolved the issues we should return this.
I have proposed patches to return these.
Thanks
Gary

On 6/4/17, 4:15 PM, "Jeremy Stanley" <fu...@yuggoth.org> wrote:

On 2017-06-04 11:35:16 +0000 (+0000), Gary Kotton wrote:
> The bot that runs for the requirements update sometimes does not
> update the vmware-nsx project. I am not sure if this happens with
> other projects. Does anyone know how we can trouble shoot this?

I assume you mean the openstack/vmware-nsxlib repository? I see a
proposed update to it as of 04:40 UTC today:

https://review.openstack.org/470566

If you're talking about the actual openstack/vmware-nsx (not ...lib)
repository, it's not listed in the projects.txt file in
openstack/requirements:

http://git.openstack.org/cgit/openstack/requirements/tree/projects.txt

Looks like it was removed a few months ago:

https://review.openstack.org/440882

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

[openstack-dev] [infra] Update for global requirements

[Gary Kotton]

Hi,
The bot that runs for the requirements update sometimes does not update the 
vmware-nsx project. I am not sure if this happens with other projects. Does 
anyone know how we can trouble shoot this?
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

[openstack-dev] [neutron][l2gw] OVS code currently broken

[Gary Kotton]

Hi,
Please note that the L2 GW code is currently broken due to the commit 
e6333593ae6005c4b0d73d9dfda5eb47f40dd8da
If someone has the cycles can they please take a look.
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

Re: [openstack-dev] [Openstack][Neutron]Why we use secuirity group which only support dispatching whiltelist rules?

[Gary Kotton]

Hi,
I would like us to think of considering enabling an API that would allow 
‘deny’, for example an admin could overwrite a tenant’s security groups. For 
example, and admin may not want a specific source range to access the tenants 
VM’s. The guys working on FWaaS say that this may happen in V2, but that looks 
very far away. Making this change in Neutron would be pretty simple and give us 
a nice feature add. 
If you would like to work on this I would be happy to develop this with you. It 
could be added an extension.
Thanks
Gary

On 4/24/17, 6:37 AM, "Ihar Hrachyshka"  wrote:

All traffic is denied by default. OpenStack security groups API is
modeled to reflect what AWS does. You may find your needs better
served by fwaas plugin for neutron that is not constrained by AWS
compatibility.

Ihar

On Sun, Apr 23, 2017 at 8:33 PM, 田明明  wrote:
> Can we add an "action" to security group rule api, so that we could 
dispatch
> rules with "deny" action? Until now， security group only supports add
> white-list rules but this couldn't satisfy many people's needs.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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


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

Re: [Openstack] [gerrit] Co-authorship/ownership

[Gary Kotton]

Please see https://wiki.openstack.org/wiki/GitCommitMessages

On 4/25/17, 4:34 PM, "Eric Fried"  wrote:

Howdy folks.

What's the protocol when a change set has more than one (significant)
contributor?  I've seen this "Co-Authored-By" tag in commit messages -
under what circumstances is it necessary/appropriate to use that?  What
official or procedural significance does it have, if any?

Is it possible to change the owner of a change set (e.g. if someone else
has become the primary contributor, or if the original owner has left
the project)?  Is that recommended?

Is there any other process or metadata that applies to this topic?

Thanks,
Eric Fried (efried)

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [neutron] Engine facade

[Gary Kotton]

Thanks Kevin,
We will also need https://review.openstack.org/#/c/453048/ in some way or form.

From: Kevin Benton <ke...@benton.pub>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Tuesday, April 4, 2017 at 1:18 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] Engine facade

I worked with Gary on IRC and discovered that we aren't making use of the flag 
added in [1], which makes adoption harder. I've proposed a patch to 
neutron-lib[2] that should alleviate some of these issues.

1. https://bugs.launchpad.net/oslo.db/+bug/1664643
2. https://review.openstack.org/#/c/453063/

On Tue, Apr 4, 2017 at 3:11 AM, Anna Taraday 
<akamyshnik...@mirantis.com<mailto:akamyshnik...@mirantis.com>> wrote:
Hi!

This errors does not mean that foreign key usage is broken. This means that 
there is a mess with transactions. As you paste small piece of trace it is hard 
to say why this happen, but during my work I saw such errors and resolve them. 
And probably you need to revisit your unit tests.

Please, send me email directly with links for traces, does this happen on 
master branch, does it happen on one of your changes - it is hard to guess.


On Tue, Apr 4, 2017 at 11:16 AM Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
The problem that we have is that any foreign key usage under transactions is 
now broken. An example of an exception that is raised is:

DBReferenceError: (sqlite3.IntegrityError) FOREIGN KEY constraint failed 
[SQL: u'INSERT INTO neutron_nsx_firewall_section_mappings (created_at, 
updated_at, neutron_id, nsx_id) VALUES (?, ?, ?, ?)'] [parameters: ('2017-04-04 
06:48:25.595118', None, '6a086bf1-b1c9-495f-bfca-810d6638e3fa', 
'2563cd05-edd9-4c7f-9708-857a129e2642')]

This is a major refactor in the plugin (which I guess is part and parcel of 
rolling with the punches). I am just concerned if we are the only folks that 
have affected by this.
Thanks
Gary

From: Gary Kotton <gkot...@vmware.com<mailto:gkot...@vmware.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 3, 2017 at 3:14 PM

To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Engine facade

Hi,
We needed to make all of those changes to just get the plugin to pass unit 
tests and CI. We are still seeing lots of issues and need to look deeper. The 
façade changes have caused a lot of instability issues. I am not 100% sure why. 
Issues that we have seen:
1. object creation under a transaction broke
2. deleting DB entries under transaction also broke
Thanks
Gary


From: Anna Taraday 
<akamyshnik...@mirantis.com<mailto:akamyshnik...@mirantis.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 3, 2017 at 11:53 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Engine facade

Hi!

I'm a little confused change https://review.openstack.org/#/c/452539/ is about 
switching for new facade, does the master branch fails the same?

On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Yes, sorry my bad for not adding it - 
http://logs.openstack.org/39/452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/14c019c/testr_results.html.gz
Please see the test test_create_port_dns_name
Thanks
Gary

From: Kevin Benton <ke...@benton.pub>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 3, 2017 at 12:56 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Engine facade

Do you have a link to a traceback?

On Apr 2, 2017 09:25, "Gary Kotton" 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
The change https://review.openstack.org/#/c/402750/ has broken the vmware-nsx 
plugin. I am not sure if this has had effect on any other decomposed plugins.
One of the issues that we have is when we create a PortDNS object under a 
transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError) 
FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id, 
current_dns_name, current_dns_domain, previous_dns_name, previous_dns_domain, 
dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters: 
('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'', u'port-dns-name')]
Any ideas?
Thanks
Gary

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ.

Re: [openstack-dev] [neutron] Engine facade

[Gary Kotton]

Hi,
The problem that we have is that any foreign key usage under transactions is 
now broken. An example of an exception that is raised is:

DBReferenceError: (sqlite3.IntegrityError) FOREIGN KEY constraint failed 
[SQL: u'INSERT INTO neutron_nsx_firewall_section_mappings (created_at, 
updated_at, neutron_id, nsx_id) VALUES (?, ?, ?, ?)'] [parameters: ('2017-04-04 
06:48:25.595118', None, '6a086bf1-b1c9-495f-bfca-810d6638e3fa', 
'2563cd05-edd9-4c7f-9708-857a129e2642')]

This is a major refactor in the plugin (which I guess is part and parcel of 
rolling with the punches). I am just concerned if we are the only folks that 
have affected by this.
Thanks
Gary

From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, April 3, 2017 at 3:14 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] Engine facade

Hi,
We needed to make all of those changes to just get the plugin to pass unit 
tests and CI. We are still seeing lots of issues and need to look deeper. The 
façade changes have caused a lot of instability issues. I am not 100% sure why. 
Issues that we have seen:
1. object creation under a transaction broke
2. deleting DB entries under transaction also broke
Thanks
Gary


From: Anna Taraday <akamyshnik...@mirantis.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, April 3, 2017 at 11:53 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] Engine facade

Hi!

I'm a little confused change https://review.openstack.org/#/c/452539/ is about 
switching for new facade, does the master branch fails the same?

On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Yes, sorry my bad for not adding it - 
http://logs.openstack.org/39/452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/14c019c/testr_results.html.gz
Please see the test test_create_port_dns_name
Thanks
Gary

From: Kevin Benton <ke...@benton.pub>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 3, 2017 at 12:56 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Engine facade

Do you have a link to a traceback?

On Apr 2, 2017 09:25, "Gary Kotton" 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
The change https://review.openstack.org/#/c/402750/ has broken the vmware-nsx 
plugin. I am not sure if this has had effect on any other decomposed plugins.
One of the issues that we have is when we create a PortDNS object under a 
transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError) 
FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id, 
current_dns_name, current_dns_domain, previous_dns_name, previous_dns_domain, 
dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters: 
('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'', u'port-dns-name')]
Any ideas?
Thanks
Gary

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Regards,
Ann Taraday
__
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] Engine facade

[Gary Kotton]

Hi,
We needed to make all of those changes to just get the plugin to pass unit 
tests and CI. We are still seeing lots of issues and need to look deeper. The 
façade changes have caused a lot of instability issues. I am not 100% sure why. 
Issues that we have seen:
1. object creation under a transaction broke
2. deleting DB entries under transaction also broke
Thanks
Gary


From: Anna Taraday <akamyshnik...@mirantis.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, April 3, 2017 at 11:53 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] Engine facade

Hi!

I'm a little confused change https://review.openstack.org/#/c/452539/ is about 
switching for new facade, does the master branch fails the same?

On Mon, Apr 3, 2017 at 8:35 AM Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Yes, sorry my bad for not adding it - 
http://logs.openstack.org/39/452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/14c019c/testr_results.html.gz
Please see the test test_create_port_dns_name
Thanks
Gary

From: Kevin Benton <ke...@benton.pub>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 3, 2017 at 12:56 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] Engine facade

Do you have a link to a traceback?

On Apr 2, 2017 09:25, "Gary Kotton" 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
The change https://review.openstack.org/#/c/402750/ has broken the vmware-nsx 
plugin. I am not sure if this has had effect on any other decomposed plugins.
One of the issues that we have is when we create a PortDNS object under a 
transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError) 
FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id, 
current_dns_name, current_dns_domain, previous_dns_name, previous_dns_domain, 
dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters: 
('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'', u'port-dns-name')]
Any ideas?
Thanks
Gary

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Regards,
Ann Taraday
__
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] How does tag gets allocated to VM ports ?

[Gary Kotton]

Hi,
This is done by the agents. For example please see 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L1639
Thanks
Gary

From: Vikash Kumar 
Reply-To: OpenStack List 
Date: Monday, April 3, 2017 at 9:46 AM
To: OpenStack List 
Subject: [openstack-dev] [openstack] How does tag gets allocated to VM ports ?

Hi,
   How does "tag" gets assigned to openvswitch port ?
Port "tap319bae97-0b"
tag: 1
Interface "tap319bae97-0b"

It is done by openvswitch-agent, but can someone point me to the details? Is 
this has anything to do with network (segment-id) or is it just local to 
openvswitch ?

--
Regards,
Vikash
__
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] Engine facade

[Gary Kotton]

Yes, sorry my bad for not adding it - 
http://logs.openstack.org/39/452539/2/check/gate-vmware-nsx-python27-ubuntu-xenial/14c019c/testr_results.html.gz
Please see the test test_create_port_dns_name
Thanks
Gary

From: Kevin Benton <ke...@benton.pub>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, April 3, 2017 at 12:56 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] Engine facade

Do you have a link to a traceback?

On Apr 2, 2017 09:25, "Gary Kotton" 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
The change https://review.openstack.org/#/c/402750/ has broken the vmware-nsx 
plugin. I am not sure if this has had effect on any other decomposed plugins.
One of the issues that we have is when we create a PortDNS object under a 
transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError) 
FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id, 
current_dns_name, current_dns_domain, previous_dns_name, previous_dns_domain, 
dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters: 
('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'', u'port-dns-name')]
Any ideas?
Thanks
Gary

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

[openstack-dev] [neutron] Engine facade

[Gary Kotton]

Hi,
The change https://review.openstack.org/#/c/402750/ has broken the vmware-nsx 
plugin. I am not sure if this has had effect on any other decomposed plugins.
One of the issues that we have is when we create a PortDNS object under a 
transaction we get an exception: DBReferenceError: (sqlite3.IntegrityError) 
FOREIGN KEY constraint failed [SQL: u'INSERT INTO portdnses (port_id, 
current_dns_name, current_dns_domain, previous_dns_name, previous_dns_domain, 
dns_name) VALUES (?, ?, ?, ?, ?, ?)'] [parameters: 
('2f2039ac-e7e6-4cc3-a8a0-3298089d4afb', u'', u'', u'', u'', u'port-dns-name')]
Any 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

Re: [openstack-dev] [neutron] - Adding Miguel Lavalle to neutron-drivers team

[Gary Kotton]

+1

On 3/31/17, 12:55 AM, "Ihar Hrachyshka"  wrote:

On Thu, Mar 30, 2017 at 2:11 PM, Kevin Benton  wrote:
> Hi,
>
> I would like to add Miguel Lavalle (mlavalle) to the Neutron drivers team
> [1].

It's not completely clear if you seek support here, but in case you do, +1.

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


__
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] running control plane on a vmware VM

[Gary Kotton]

Hi,
You will need to set your switches to promiscuous mode. This is due to the fact 
that the traffic will be using MAC addresses from OpenStack and not the VMware 
ones.
Thanks
Gary

From: Manuel Sopena Ballesteros 
Date: Friday, March 31, 2017 at 4:05 AM
To: "openstack@lists.openstack.org" 
Subject: [Openstack] running control plane on a vmware VM

Hi all,

I deployed openstack on a vmware vm using kolla-ansible. The installation was 
successful but my router namespace cannot ping the internet and I don’t know 
why.

I checked with the openstack IRC channel and my guess is that vmware is 
blocking the traffic from the quantum gateway but I don’t know how to prove 
this.

Am I doing something stupid by running the control plane on a vmware vm? Has 
anyone done this before? How can I troubleshoot deeper so I can prove my theory?

Thank you very much

Manuel Sopena Ballesteros | Big data Engineer
Garvan Institute of Medical Research
The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010
T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: 
manuel...@garvan.org.au

NOTICE
Please consider the environment before printing this email. This message and 
any attachments are intended for the addressee named and may contain legally 
privileged/confidential/copyright information. If you are not the intended 
recipient, you should not read, use, disclose, copy or distribute this 
communication. If you have received this message in error please notify us at 
once by return email and then delete both messages. We accept no liability for 
the distribution of viruses or similar in electronic communications. This 
notice should not be removed.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [neutron][networking-l2gw] Project update

[Gary Kotton]

Hi,
Please see below for a current update on the status of the project.

1.   stable/ocata:

a.   a tag 10.0.0 has been created

b.   code has been updated to pass unit tests (there was a breakage as it 
was pulling master neutron)

2.   master:

a.   Due to the tag above being created we created a dummy tag to ensure 
that later versions will be used

b.   Thanks to xuqihou for kicking the wheels for the log translations 
(https://review.openstack.org/#/c/447949/)

c.   There are a few other patches that need some review cycles 
(https://review.openstack.org/#/q/project:openstack/networking-l2gw)
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

Re: [openstack-dev] [neutron][networking-l2gw] Unable to create release tag

[Gary Kotton]

Thanks!

From: Yolanda Robla Mota <yrobl...@redhat.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Thursday, March 23, 2017 at 6:33 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][networking-l2gw] Unable to create 
release tag

Hi, seems the ACL is not correctly applied. infra-root as looking at it
Best
Yolanda

On Thu, Mar 23, 2017 at 5:18 PM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
I have tried updating my gpg key and still nothing works:

gkotton@ubuntu:~/networking-l2gw$ git push gerrit tag 10.0.0
Enter passphrase for key '/home/gkotton/.ssh/id_rsa':
Counting objects: 1, done.
Writing objects: 100% (1/1), 531 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
remote: Processing changes: refs: 1, done
To 
ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git<http://ga...@review.openstack.org:29418/openstack/networking-l2gw.git>
 ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
error: failed to push some refs to 
'ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git<http://ga...@review.openstack.org:29418/openstack/networking-l2gw.git>'

Any idea here?
This is blocking people who want to package…
Thanks
Gary

On 3/21/17, 7:18 PM, "Gary Kotton" 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:

Hi,
I am still unable to do this – this is after 
https://review.openstack.org/#/c/447279/ landed.
Any ideas?
Thanks
Gary

On 3/14/17, 3:04 PM, "Jeremy Stanley" 
<fu...@yuggoth.org<mailto:fu...@yuggoth.org>> wrote:

On 2017-03-14 05:39:35 + (+), Gary Kotton wrote:
> I was asked to create a release tag for stable/ocata. This fails with:
[...]
>  ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
[...]

The ACL for that repo doesn't seem to be configured to allow it
(yet):


http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/networking-l2gw.config

The Infra Manual section documenting that permission is:

https://docs.openstack.org/infra/manual/creators.html#creation-of-tags

It also may be helpful to review the section on manually tagging
releases:

https://docs.openstack.org/infra/manual/drivers.html#tagging-a-release

Hope that helps!
--
Jeremy Stanley


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--

Yolanda Robla Mota

Principal Software Engineer, RHCSA

Red Hat

<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=KdZF5HE_HEsi52jOxKmeCNM4IRFVQRK0SZKoSE_yoOQ=0u2nAJGvRbfxBmDbeMI_bG-0cqkKHwCTyvhKl9EWECg=>

C/Avellana 213

Urb Portugal

yrobl...@redhat.com<mailto:yrobl...@redhat.com>M: 
+34605641639<https://urldefense.proofpoint.com/v2/url?u=http-3A__redhatemailsignature-2Dmarketing.itos.redhat.com_=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=KdZF5HE_HEsi52jOxKmeCNM4IRFVQRK0SZKoSE_yoOQ=wUe1Nmt9zm92ENJoVJDBNvr5hB4vrUlutxYz20Vqj2M=>
[https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png]<https://urldefense.proofpoint.com/v2/url?u=https-3A__red.ht_sig=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=KdZF5HE_HEsi52jOxKmeCNM4IRFVQRK0SZKoSE_yoOQ=yT42_97aPECspX0Mwz63Njz89LqUbjitj8RT9YcHstU=>
__
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][networking-l2gw] Unable to create release tag

[Gary Kotton]

Hi,
I have tried updating my gpg key and still nothing works:

gkotton@ubuntu:~/networking-l2gw$ git push gerrit tag 10.0.0
Enter passphrase for key '/home/gkotton/.ssh/id_rsa': 
Counting objects: 1, done.
Writing objects: 100% (1/1), 531 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
remote: Processing changes: refs: 1, done
To ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git
 ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
error: failed to push some refs to 
'ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git'

Any idea here?
This is blocking people who want to package…
Thanks
Gary

On 3/21/17, 7:18 PM, "Gary Kotton" <gkot...@vmware.com> wrote:

Hi,
I am still unable to do this – this is after 
https://review.openstack.org/#/c/447279/ landed.
Any ideas?
Thanks
Gary

On 3/14/17, 3:04 PM, "Jeremy Stanley" <fu...@yuggoth.org> wrote:

On 2017-03-14 05:39:35 + (+), Gary Kotton wrote:
> I was asked to create a release tag for stable/ocata. This fails with:
[...]
>  ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
[...]

The ACL for that repo doesn't seem to be configured to allow it
(yet):


http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/networking-l2gw.config

The Infra Manual section documenting that permission is:

https://docs.openstack.org/infra/manual/creators.html#creation-of-tags

It also may be helpful to review the section on manually tagging
releases:

https://docs.openstack.org/infra/manual/drivers.html#tagging-a-release

Hope that helps!
-- 
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


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


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

Re: [openstack-dev] [neutron][networking-l2gw] Unable to create release tag

[Gary Kotton]

Hi,
I am still unable to do this – this is after 
https://review.openstack.org/#/c/447279/ landed.
Any ideas?
Thanks
Gary

On 3/14/17, 3:04 PM, "Jeremy Stanley" <fu...@yuggoth.org> wrote:

On 2017-03-14 05:39:35 +0000 (+0000), Gary Kotton wrote:
> I was asked to create a release tag for stable/ocata. This fails with:
[...]
>  ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
[...]

The ACL for that repo doesn't seem to be configured to allow it
(yet):


http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/networking-l2gw.config

The Infra Manual section documenting that permission is:

https://docs.openstack.org/infra/manual/creators.html#creation-of-tags

It also may be helpful to review the section on manually tagging
releases:

https://docs.openstack.org/infra/manual/drivers.html#tagging-a-release

Hope that helps!
-- 
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


__
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][tap-as-a-service] neutron-lib breakage

[Gary Kotton]

Hi,
Can the tap guys please look at https://review.openstack.org/447277. All 
projects using the tap project are currently stuck
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

[openstack-dev] [neutron][networking-l2gw] Unable to create release tag

[Gary Kotton]

Hi,
I was asked to create a release tag for stable/ocata. This fails with:

gkotton@ubuntu:~/networking-l2gw$ git push gerrit tag 10.0.0
Enter passphrase for key '/home/gkotton/.ssh/id_rsa':
Counting objects: 1, done.
Writing objects: 100% (1/1), 533 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
remote: Processing changes: refs: 1, done
To ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git
 ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
error: failed to push some refs to 
'ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git'

Any idea?
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

Re: [openstack-dev] [neutron][infra] Any idea why patch is not gating

[Gary Kotton]

Thanks!
439565 was abandoned. Sorry for the trouble


On 3/6/17, 5:32 PM, "Paul Belanger" <pabelan...@redhat.com> wrote:

On Mon, Mar 06, 2017 at 03:44:59PM +0000, Gary Kotton wrote:
> Hi,
> When we recheck https://review.openstack.org/#/c/388157/ or any patch 
that depends on this one, they just hang. Any idea why?
> Thanks
> Gary

After looking at the zuul debug.log, it appears to be because 439565 [1] 
had an
incorrect Depends-On header, it created a dependency cycle on itself.

I had to rebase and recheck 388157, but it is working now.

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

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


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


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

Re: [openstack-dev] [neutron][sfc][release] stable/ocata version

[Gary Kotton]

Great! Thanks for the update

From: "Armando M." <arma...@gmail.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, March 6, 2017 at 5:03 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][sfc][release] stable/ocata version



On 5 March 2017 at 23:24, Ihar Hrachyshka 
<ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
With https://review.openstack.org/#/c/437699/ in, stadium projects
will no longer have any other option but to follow the common
schedule. That change is new for Pike+ so we may still see some issues
with Ocata release process.

The stable branch for Ocata is being cut in [1]. Everything else that targets 
Pike is a go.

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


Ihar

On Sun, Mar 5, 2017 at 8:03 PM, Jeffrey Zhang 
<zhang.lei@gmail.com<mailto:zhang.lei@gmail.com>> wrote:
> Add [release] tag in subject.
>
> Do not follow the OpenStack release schedule will cause lots of issues. Like
> requirements changes, patches is merged which should not be merged into
> stable.
>
> It also may break the deploy project release schedule( like Kolla will not
> be
> released until sfc release ocata branch and tag ).
>
> I hope sfc team could follow the OpenStack release schedule, even though it
> may
> cause some cherry-pick, but it is safer and how OpenStack project live.
>
>
> On Sun, Mar 5, 2017 at 3:44 PM, Gary Kotton 
> <gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
>>
>> Please note that things are going to start to get messy now – there are
>> changes in neutron that break master and these will affect the cutting of
>> the stable version. One example is https://review.openstack.org/441654
>>
>>
>>
>> So I suggest cutting a stable ASAP and then cherrypicking patches
>>
>>
>>
>> From: Gary Kotton <gkot...@vmware.com<mailto:gkot...@vmware.com>>
>> Reply-To: OpenStack List 
>> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>> Date: Sunday, March 5, 2017 at 9:36 AM
>>
>>
>> To: OpenStack List 
>> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
>>
>>
>>
>> Thanks!
>>
>>
>>
>> From: Jeffrey Zhang <zhang.lei@gmail.com<mailto:zhang.lei@gmail.com>>
>> Reply-To: OpenStack List 
>> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>> Date: Sunday, March 5, 2017 at 9:12 AM
>> To: OpenStack List 
>> <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>> Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version
>>
>>
>>
>> This is talked in [0]. sfc team said
>>
>>
>>
>> > we will pull a stable/ocata branch around end of Feb or early March the
>> > latest.
>>
>>
>>
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html
>>
>>
>>
>> On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton 
>> <gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
>>
>> Hi,
>>
>> We are pretty blocked at the moment with our gating on stable/ocata. This
>> is due to the fact that there is no networking-sfc version tagged for ocata.
>>
>> Is there any ETA for this?
>>
>> Thanks
>>
>> Gary
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>
>> --
>>
>> Regards,
>>
>> Jeffrey Zhang
>>
>> Blog: 
>> http://xcodest.me<https://urldefense.proofpoint.com/v2/url?u=http-3A__xcodest.me=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=e9oFxLk6K7GOvDVL0y3uKlSTQHtU9tnXcMGHL46H37I=9fysx1MmSeqhencLNvi8w-M1Ryv8UPPz6Mdx6bUkveA=>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-re

[openstack-dev] [neutron][infra] Any idea why patch is not gating

[Gary Kotton]

Hi,
When we recheck https://review.openstack.org/#/c/388157/ or any patch that 
depends on this one, they just hang. Any idea why?
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

Re: [openstack-dev] [neutron][sfc] stable/ocata version

[Gary Kotton]

Please note that things are going to start to get messy now – there are changes 
in neutron that break master and these will affect the cutting of the stable 
version. One example is https://review.openstack.org/441654

So I suggest cutting a stable ASAP and then cherrypicking patches

From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Sunday, March 5, 2017 at 9:36 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version

Thanks!

From: Jeffrey Zhang <zhang.lei@gmail.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Sunday, March 5, 2017 at 9:12 AM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][sfc] stable/ocata version

This is talked in [0]. sfc team said

​> we will pull a stable/ocata branch around end of Feb or early March the 
latest.

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112580.html

On Sun, Mar 5, 2017 at 3:01 PM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
Hi,
We are pretty blocked at the moment with our gating on stable/ocata. This is 
due to the fact that there is no networking-sfc version tagged for ocata.
Is there any ETA for this?
Thanks
Gary


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



--
Regards,
Jeffrey Zhang
Blog: 
http://xcodest.me<https://urldefense.proofpoint.com/v2/url?u=http-3A__xcodest.me_=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=6_isL-K77U2G5VKK49-mlfFOK02rPelnU35II7kFuaA=g3cKOpPjE5Oe13XGD9APDryFCpweg0haylD5oit44Yc=>
__
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