from:"Bernard Cafarelli"

Old bug on specific env rally failure and many things changed since,
closing

** Changed in: neutron
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1555670

Title:
  L3 HA: MessagingTimeout during running  rally
  create_and_delete_routers

Status in neutron:
  Invalid

Bug description:
  During running rally test create_and_delete_routers (standard test) on
  env with L3 HA enabled (3 controllers, 1 compute, liberty) getting
  about 50% failure with "Not enough l3 agents available to ensure HA.
  Minimum required 2, available 1."

  Logs of l3 agent full of errors
  http://paste.openstack.org/show/490011/, so agent considered to be
  dead for server http://paste.openstack.org/show/490010/ If concurrency
  for test is  lower than 10 the number of failing tests is reduced.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1555670/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1598337] Re: lbaasv2:The range of weight in member is usually [0, 255], not [0, 256]

neutron-lbaas is retired, closing bug

** Changed in: neutron
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1598337

Title:
  lbaasv2:The range of weight in member is usually [0,255], not [0,256]

Status in neutron:
  Won't Fix

Bug description:
  Weight in member is created with the range [0,256],
  'weight': {'allow_post': True, 'allow_put': True,
 'default': 1,
 'validate': {'type:range': [0, 256]},
 'convert_to': attr.convert_to_int,
 'is_visible': True},

  Usually,this is [0,255]

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1598337/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1718509] Re: python paste dumping raw input

Removing neutron as it is purely in common code and paste itself

** No longer affects: neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1718509

Title:
  python paste dumping raw input

Status in paste:
  New
Status in python-eventlet package in Ubuntu:
  Confirmed

Bug description:
  juju-7de47d-1-lxd-2:~ telnet localhost 9696
  Trying 127.0.0.1...
  Connected to localhost.
  Escape character is '^]'.
  GET cross_site_scripting.nasl

  HTTP/1.1 500 Internal Server Error
  Content-Type: text/plain
  Content-Length: 596
  Date: Tue, 19 Sep 2017 20:17:09 GMT
  Connection: close

  Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 481, in 
handle_one_response
  result = self.application(self.environ, start_response)
  File "/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 198, in __call__
  path_info = self.normalize_url(path_info, False)[1]
  File "/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 122, in 
normalize_url
  "URL fragments must start with / or http:// (you gave %r)" % url)
  AssertionError: URL fragments must start with / or http:// (you gave 
'cross_site_scripting.nasl')
  Connection closed by foreign host.
  ➜ juju-7de47d-1-lxd-2:~

   juju-7de47d-1-lxd-2:~ telnet localhost 9696
  Trying 127.0.0.1...
  Connected to localhost.
  Escape character is '^]'.
  GET document.cookie%22testgppq=1191;%22

  HTTP/1.1 500 Internal Server Error
  Content-Type: text/plain
  Content-Length: 602
  Date: Tue, 19 Sep 2017 20:33:26 GMT
  Connection: close

  Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 481, in 
handle_one_response
  result = self.application(self.environ, start_response)
  File "/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 198, in __call__
  path_info = self.normalize_url(path_info, False)[1]
  File "/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 122, in 
normalize_url
  "URL fragments must start with / or http:// (you gave %r)" % url)
  AssertionError: URL fragments must start with / or http:// (you gave 
'document.cookie"testgppq=1191;"')
  Connection closed by foreign host.
  ➜ juju-7de47d-1-lxd-2:~

To manage notifications about this bug go to:
https://bugs.launchpad.net/paste/+bug/1718509/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1921514] Re: VPNaaS strongSwan driver does not reload secrets

Patch was merged a while ago and backported in neutron-vpnaas, and does
not affect neutron itself, updating status

** Changed in: neutron-vpnaas (Ubuntu)
Status: New => Fix Released

** No longer affects: neutron

--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1921514

Title:
VPNaaS strongSwan driver does not reload secrets

Status in neutron-vpnaas package in Ubuntu:
Fix Released

Bug description:
When a new IPsec Site Connection is added to VPN Service which already
hosts a connection, it is not being properly propagated to L3 Agent
with vpnaas plugin using strongSwan driver.

See following fragment: https://opendev.org/openstack/neutron-

vpnaas/src/branch/master/neutron_vpnaas/services/vpn/device_drivers/strongswan_ipsec.py#L159-L171

`ipsec reload` command only reloads the ipsec.conf configuration. If a
new connection is added with different PSK credentials, then we also
need to run `ipsec rereadsecrets`, otherwise charon will try to use
"%any - " credentials.

Preparations:
1. Enable charon filelog in StrongSwan template. Add the following lines to
/etc/neutron/l3_agent.ini:
[strongswan]
strongswan_config_template = /etc/neutron/strongswan.conf.template
2. Create /etc/neutron/strongswan.conf.template:
http://paste.openstack.org/show/803952/
3. AppArmor systems only - temporarily place charon in complain mode in order
to allow it to write logs to /var/log/neutron directory: aa-complain
/usr/lib/ipsec/charon
4. Restart neutron-l3-agent so it will regenerate all VPN configurations with
logging enabled.

Steps to reproduce the problem:
1. Create a new router.
2. Create a VPN service associated with new router.
3. Create a IPsec Site Connection and associate it with VPN service.
4. Create another IPsec Site Connection, with different PSK in the same VPN
service.

Expected behavior:
New IPsec Site Connection should be in Active state.

Actual behavior:
New IPsec Site Connection does not start. Authentication errors can be seen
on both sides. See the following log snippet which should be present in
/var/log/neutron/neutron-vpnaas-charon-.log:
http://paste.openstack.org/show/803954/

Discovered on OpenStack Rocky-based deployment, but this issue still
seems to be present in master branch of neutron-vpnaas (see the
opendev.org link above)

I am attaching a patch which should fix the issue, I have deployed it
in a test environment and initial tests show that it works correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/neutron-vpnaas/+bug/1921514/+subscriptions

--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1996788] Re: The virtual network is broken on the node after neutron-openvswitch-agent is restarted if RPC requests return an error for a while.

2022-11-18 Thread Bernard Cafarelli

** Tags added: ovs

** Changed in: neutron
   Status: New => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1996788

Title:
  The virtual network is broken on the node after neutron-openvswitch-
  agent is restarted if RPC requests return an error for a while.

Status in neutron:
  Opinion

Bug description:
  We ran into a problem in our openstack cluster, when traffic does not go 
through the virtual network on the node on which the neutron-openvswitch-agent 
was restarted.
  We had an update from one version of the Openstack to another and by chance 
we had a inconsistency of the DB and neutron-server: any port select from the 
DB returned an error.
  For a while neutron-openvswitch-agent (just after restart) couldn't get any 
information via RCP in its rpc_loop iterations due to DB/neutron-server 
inconsistency.
  But after updating the database, we got a broken virtual network on the node 
where the neutron-openvswitch-agent was restarted.

  It seems to me that I have found a problem place in the logic of 
neutron-ovs-agent.
  To demonstrate, better to emulate the RPC request fail from neutron-ovs-agent 
to neutron-server.

  Here are the steps to reproduce on devstack setup from the master branch.
  Two nodes: node0 is controller, node1 is compute.

  0) Prepare a vxlan based network and a VM.
  [root@node0 ~]# openstack network create net1
  [root@node0 ~]# openstack subnet create sub1 --network net1 --subnet-range 
192.168.1.0/24
  [root@node0 ~]# openstack server create vm1 --network net1 --flavor m1.tiny 
--image cirros-0.5.2-x86_64-disk --host node1

  Just after creating the VM, there is a message in the devstack@q-agt
  logs:

  Nov 16 09:53:35 node1 neutron-openvswitch-agent[374810]: INFO
  neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [None
  req-77753b72-cb23-4dae-b68a-7048b63faf8b None None] Assigning 1 as
  local vlan for net-id=710bcfcd-44d9-445d-a895-8ec522f64016, seg-id=466

  So, local vlan which is used on node1 for the network is `1`
  A ping from the node0 to the VM on node1 success works:

  [root@node0 ~]# ip netns exec qdhcp-710bcfcd-44d9-445d-a895-8ec522f64016 ping 
192.168.1.211
  PING 192.168.1.211 (192.168.1.211) 56(84) bytes of data.
  64 bytes from 192.168.1.211: icmp_seq=1 ttl=64 time=1.86 ms
  64 bytes from 192.168.1.211: icmp_seq=2 ttl=64 time=0.891 ms

  1) Now, please don't misunderstand me, I don't want to be read that I'm 
patching the code and then clearly something won't work,
  I just want to emulate a problem that's hard enough to reproduce in a normal 
way but it can.
  So, emulate a problem that method get_resource_by_id returns an error just 
after neutron-ovs-agent restart (RPC based method actually):

  [root@node1 neutron]# git diff
  diff --git a/neutron/agent/rpc.py b/neutron/agent/rpc.py
  index 9a133afb07..299eb25981 100644
  --- a/neutron/agent/rpc.py
  +++ b/neutron/agent/rpc.py
  @@ -327,6 +327,11 @@ class CacheBackedPluginApi(PluginApi):

   def get_device_details(self, context, device, agent_id, host=None,
  agent_restarted=False):
  +import time
  +if not hasattr(self, '_stime'):
  +self._stime = time.time()
  +if self._stime + 5 > time.time():
  +raise Exception('Emulate RPC error in get_resource_by_id call')
   port_obj = self.remote_resource_cache.get_resource_by_id(
   resources.PORT, device, agent_restarted)
   if not port_obj:

  
  Restart neutron-openvswitch-agent agent and try to ping after 1-2 mins:

  [root@node1 ~]# systemctl restart devstack@q-agt

  [root@node0 ~]# ip netns exec qdhcp-710bcfcd-44d9-445d-a895-8ec522f64016 ping 
-c 2 192.168.1.234
  PING 192.168.1.234 (192.168.1.234) 56(84) bytes of data.

  --- 192.168.1.234 ping statistics ---
  2 packets transmitted, 0 received, 100% packet loss, time 1058ms

  [root@node0 ~]#

  Ping doesn't work.
  Just after the neutron-ovs-agent restart and when the RPC starts working 
correctly, there are logs:

  Nov 16 09:55:13 node1 neutron-openvswitch-agent[375032]: INFO 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [None 
req-135ae96d-905e-485f-8c1f-b0a70616b4c7 None None] Assigning 2 as local vlan 
for net-id=710bcfcd-44d9-445d-a895-8ec522f64016, seg-id=466
  Nov 16 09:55:13 node1 neutron-openvswitch-agent[375032]: INFO 
neutron.agent.securitygroups_rpc [None req-135ae96d-905e-485f-8c1f-b0a70616b4c7 
None None] Preparing filters for devices 
{'40d82f69-274f-4de5-84d9-6290159f288b'}
  Nov 16 09:55:13 node1 neutron-openvswitch-agent[375032]: INFO 
neutron.agent.linux.openvswitch_firewall.firewall [None 
req-135ae96d-905e-485f-8c1f-b0a70616b4c7 None None] Initializing port 
40d82f69-274f-4de5-84d9-6290159f288b that was already initialized.

  So, `Assigning 2 as local vlan` followed by `Initializing port ...
  that was already

[Yahoo-eng-team] [Bug 1996528] Re: No output for "openstack port list --project project_name" in case of non-admin user

2022-11-15 Thread Bernard Cafarelli

After checking on IRC [0], this is working as designed on the keystone side, 
regular users aren't allowed to list projects
As this is the way used to find the project ID, this is why non-admin users get 
an empty list

[0] https://meetings.opendev.org/irclogs/%23openstack-
neutron/%23openstack-neutron.2022-11-15.log.html#t2022-11-15T14:53:04

** Changed in: neutron
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1996528

Title:
  No output for "openstack port list  --project project_name" in case of
  non-admin user

Status in neutron:
  Won't Fix

Bug description:
  Bug
  
  openstack port list --project project_id command works for both admin and 
non-admin users.
  openstack port list --project project_name command works for only admin users.

  
  Expected behavior
  ==
  openstack port list --project project_name command should work for both admin 
and non-admin users.

  Steps to reproduce
  ===
  1. source openrc admin admin
  2. openstack port list --project [this works]
  3, source openrc demo demo
  4. openstack port list --project   [this works]
  5. openstack port list --project   [No output]

  On running with --debug flag, seems like non-admin(i.e. demo) users
  don't have authorization to list projects and so name resolution from
  project_name to project_id fails. The query forwarded to neutron with
  project_name instead of project_id. The neutron then filters DB using
  {project_id: project_name} and query returns empty result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1996528/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1912320] Re: TestTimer breaks VPNaaS functional tests

** Changed in: neutron
Status: Fix Committed => Fix Released

--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1912320

Title:
TestTimer breaks VPNaaS functional tests

Status in neutron:
Fix Released

Bug description:
Some functional tests for neutron-vpnaas make use of the NamespaceFixture.
If the tests are run in combination with a recent neutron version some tests
fail because the TestTimer raises a TestTimerTimeout even if the namespace
cleanup finishes before the timeout.

In the test setup the tox env for dsvm-functional-sswan will normally
install neutron 17.0.0 (victoria), but for my tests I needed a recent
neutron, so I installed it as an additional step in the setup of the tox env.

The test setup steps are like these, on an Ubuntu 20.04 host:

git clone https://git.openstack.org/openstack-dev/devstack
git clone https://opendev.org/openstack/neutron
git clone https://opendev.org/openstack/neutron-vpnaas
cd neutron-vpnaas
VENV=dsvm-functional-sswan ./tools/configure_for_vpn_func_testing.sh
../devstack -i
tox -e dsvm-functional-sswan --notest
source .tox/dsvm-functional-sswan/bin/activate
python -m pip install ../neutron
deactivate

Then run the neutron-vpnaas functional tests:

tox -e dsvm-functional-sswan

Some tests fail and you see the TestTimerTimeout exception.

The tests were fine with neutron 17.0.0.
The TestTimer was introduced later.
See
Change set https://review.opendev.org/c/openstack/neutron/+/754938/
Related bug https://bugs.launchpad.net/neutron/+bug/1838793

I could narrow the problem with the TestTimer down.
In at least one neutron-vpnaas test

(neutron_vpnaas.tests.functional.strongswan.test_netns_wrapper.TestNetnsWrapper.test_netns_wrap_success)
the NamespaceFixture is used.
The TestTimer is set up, the test completes and the namespace is deleted
successfully before the 5 seconds of the timer are over. But shortly after
that the timer still fires.

The problem is the following: on timer start the old signal handler is
stored (Handler.SIG_DFL in my case) and the remaining time of any existing
alarm (in my case 0). On exit the signal handler is supposed to be reset
and the alarm too. But neither happens.
The signal handler is not set back, because Handler.SIG_DFL is falsy.
The alarm is not stopped because the old value was 0 (there was no ongoing
alarm). So in the end the alarm started by TestTimer will eventually be
signalled.

References:
Change set where the TestTimer was introduced:
https://review.opendev.org/c/openstack/neutron/+/754938/
That related to bug #1838793

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1912320/+subscriptions

--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1915341] Re: neutron-linuxbridge-agent not starting due to nf_tables rules

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1915341

Title:
  neutron-linuxbridge-agent not starting due to nf_tables rules

Status in neutron:
  Fix Released

Bug description:
  * Description
  When restarting neutron-linuxbridge-agent it fails, because it cannot remove 
nf_tables chains

  * Pre-conditions
  Openstack Ussuri on Ubuntu 20.04 installed as described in 
https://docs.openstack.org/install-guide on real hardware.

  * reproduction steps
  When you remove an instance there seem to remain some rules in neutronARP-* 
and neutronMAC-* tables. When restarting neutron-linuxbridge-agent then, it 
fails:

  neutron_lib.exceptions.ProcessExecutionError: Exit code: 4; Stdin: ; Stdout: 
; Stderr: ebtables v1.8.4 (nf_tables):  CHAIN_USER_DEL failed (Device or 
resource busy): chain neutronARP-tap0a9b5e3a-21
  INFO neutron.plugins.ml2.drivers.agent._common_agent [-] Stopping Linux 
bridge agent agent.

  After flushing these chains the agent can be started.

  # openstack --version
  openstack 5.2.0

  * severity: blocker

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1915341/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1940312] Re: Ussuri-only: Network segments are not tried out for allocation

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1940312

Title:
  Ussuri-only: Network segments are not tried out for allocation

Status in neutron:
  Fix Released

Bug description:
  * High level description: When we get a list of segments to choose
  from, and the first segment is already allocated, it fails right away
  returning RetryRequest exception, the the other segments are never
  tried out.

  I explain it a little further on the comments of PatchSet 1 here:
  https://review.opendev.org/c/openstack/neutron/+/803986/1

  This actually works at master due to a side effect of a refactoring
  that was done on
  
https://opendev.org/openstack/neutron/commit/6eaa6d83d7c7f07fd4bf04879c91582de504eff4
  to randomize the selection of segments, but on stable/ussuri, when not
  specifying the provider_network_type, we got into a situation where we
  had segments to allocate in vlan but neutron was allocating vxlan
  instead.

  * Pre-conditions: network_segment_range plugin enabled and several
  vlan project networks created on the system

  * Step-by-step reproduction steps: openstack --os-username
  'project1_admin' --os-password '**' --os-project-name project1
  --os-auth-url http://keystone.openstack.svc.cluster.local/v3 --os-
  user-domain-name Default --os-project-domain-name Default --os-
  identity-api-version 3 --os-interface internal --os-region-name
  RegionOne network create network11

  * Expected output: network created successfully (there was available
  ranges)

  * Actual output: HttpException: 503, Unable to create the network. No
  tenant network is available for allocation.

  * Version:
    ** OpenStack version: stable/ussuri
    ** Linux distro: Centos 7
    ** Deployment: StarlingX Openstack

  * Perceived severity: Major - System is usable in some circumstances

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1940312/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1892861] Re: [neutron-tempest-plugin] If paramiko SSH client connection fails because of authentication, cannot reconnect

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1892861

Title:
  [neutron-tempest-plugin] If paramiko SSH client connection fails
  because of authentication, cannot reconnect

Status in neutron:
  Fix Released

Bug description:
  In the VM boot process, cloud-init copies the SSH keys.

  If the tempest test tries to connect to the VM before the SSH keys are
  copied, the SSH client will raise a
  paramiko.ssh_exception.AuthenticationException. From this point, even
  when the SSH keys are copied into the VM, the SSH client cannot
  reconnect anymore into the VM using the pkey.

  If a bigger sleep time is added manually (to avoid this race
  condition: try to connect when the IP is available in the port but the
  SSH keys are still not present in the VM), the SSH client connects
  without any problem.

  [1]http://paste.openstack.org/show/797127/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1892861/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1905568] Re: Sanity checks missing port_name while adding tunnel port

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1905568

Title:
  Sanity checks missing port_name while adding tunnel port

Status in neutron:
  Fix Released

Bug description:
  Functions ovs_vxlan_supported and ovs_vxlan_supported from
  neutron.cmd.sanity.checks module are creating tunnel port by using
  neutron.agent.common.ovs_lib.OVSBridge.add_tunnel_port() method but
  they are not passing port name as a first argument. That argument is
  mandatory so should be passed there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1905568/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1957453] Re: [tempest ] neutron-tempest-plugin-dynamic jobs are failing

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1957453

Title:
  [tempest ] neutron-tempest-plugin-dynamic jobs  are failing

Status in neutron:
  Fix Released

Bug description:
  Failing jobs:
  neutron-tempest-plugin-dynamic-routing
  neutron-tempest-plugin-dynamic-routing-wallaby (occasionally)
  neutron-tempest-plugin-dynamic-routing-xena (occasionally)

  
  logs:

  
https://5cd2a6b7473dd470b4dc-56e56a993b15e32d01b886b8d73f896b.ssl.cf5.rackcdn.com/806689/14/check/neutron-
  tempest-plugin-dynamic-routing/f049e9f/testr_results.html

  
https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_88d/794841/10/check/neutron-
  tempest-plugin-dynamic-routing/88d9e54/testr_results.html

  
https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_beb/806689/14/check/neutron-
  tempest-plugin-dynamic-routing-xena/beb2792/testr_results.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1957453/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1978389] Re: Basic networking in Neutron - max VLAN should be 4094, not 4095

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1978389

Title:
  Basic networking in Neutron - max VLAN should be 4094, not 4095

Status in neutron:
  Fix Released

Bug description:

  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [x] This doc is inaccurate in this way: It reads "Each VLAN has an 
associated numerical ID, between 1 and 4095", but 4095 is reserved and should 
not be used for a VLAN.
  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - The mailing list: https://lists.openstack.org
   - IRC: 'openstack' channel on OFTC

  ---
  Release: 20.1.1.dev10 on 2017-11-24 14:13:00
  SHA: fda2594fe96c31695b199d5229813a091d2b6698
  Source: 
https://opendev.org/openstack/neutron/src/doc/source/admin/intro-basic-networking.rst
  URL: https://docs.openstack.org/neutron/yoga/admin/intro-basic-networking.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1978389/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1555524] Re: Any tempest plugin import failure leads other plugin tests fails

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/124

Title:
  Any tempest plugin import failure leads other plugin tests fails

Status in Ironic:
  Invalid
Status in Magnum:
  Invalid
Status in neutron:
  Fix Released
Status in tempest:
  Confirmed

Bug description:
  There is failure for all projects runs tempest plugin tests. That was
  due to fwaas tempest plugin having import error.

  When testr try to list all tests and it also list the loaded plugin
  tests, if there is any import error in any plugin, it will leads
  failure to other plugin also.

  I think plugin should work in isolated way, mean if Tempest detect any
  error from any plugin, it should just log the error and ignore that
  plugin tests and run others. Tempest does while registering conf
  options or loading plugin.

  But we should have same way for import error also.

  error-  http://logs.openstack.org/50/289650/4/check/gate-congress-
  dsvm-api/6a27be7/console.html

  2016-03-10 03:42:34.018 | all-plugin runtests: commands[1] | bash 
tools/pretty_tox.sh --concurrency=4 congress_tempest_tests
  2016-03-10 03:42:36.139 | running testr
  2016-03-10 03:42:39.664 | 
/usr/local/lib/python2.7/dist-packages/tempest_lib/__init__.py:28: 
DeprecationWarning: tempest-lib is deprecated for future bug-fixes and code 
changes in favor of tempest. Please change your imports from tempest_lib to 
tempest.lib
  2016-03-10 03:42:39.664 |   DeprecationWarning)
  2016-03-10 03:42:39.916 | running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
  2016-03-10 03:42:39.916 | OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
  2016-03-10 03:42:39.916 | OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \
  2016-03-10 03:42:39.916 | 
OS_TEST_LOCK_PATH=${OS_TEST_LOCK_PATH:-${TMPDIR:-'/tmp'}} \
  2016-03-10 03:42:39.917 | ${PYTHON:-python} -m subunit.run discover -t 
${OS_TOP_LEVEL:-./} ${OS_TEST_PATH:-./tempest/test_discover} --list 
  2016-03-10 03:42:39.917 | --- imNon-zero exit code (2) from test listing.
  2016-03-10 03:42:39.949 | perror: testr failed (3)o
  2016-03-10 03:42:39.950 | rt errors ---
  2016-03-10 03:42:39.983 | Failed to import test module: 
neutron_fwaas.tests.tempest_plugin.tests.api.test_fwaas_extensions
  2016-03-10 03:42:39.985 | Traceback (most recent call last):
  2016-03-10 03:42:39.989 |   File 
"/usr/local/lib/python2.7/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
  2016-03-10 03:42:39.989 | module = self._get_module_from_name(name)
  2016-03-10 03:42:39.989 |   File 
"/usr/local/lib/python2.7/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
  2016-03-10 03:42:39.989 | __import__(name)
  2016-03-10 03:42:39.989 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/api/test_fwaas_extensions.py",
 line 23, in 
  2016-03-10 03:42:39.989 | from 
neutron_fwaas.tests.tempest_plugin.tests.api import base
  2016-03-10 03:42:39.989 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/api/base.py",
 line 18, in 
  2016-03-10 03:42:39.989 | from neutron_fwaas.tests.tempest_plugin.tests 
import fwaas_client
  2016-03-10 03:42:39.989 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/fwaas_client.py",
 line 25, in 
  2016-03-10 03:42:39.990 | from 
neutron_fwaas.tests.tempest_plugin.services import client
  2016-03-10 03:42:39.990 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/services/client.py",
 line 18, in 
  2016-03-10 03:42:39.990 | from tempest.services.network.json import base
  2016-03-10 03:42:39.990 | ImportError: cannot import name base
  2016-03-10 03:42:39.990 | 
  2016-03-10 03:42:39.990 | Failed to import test module: 
neutron_fwaas.tests.tempest_plugin.tests.scenario.test_fwaas
  2016-03-10 03:42:39.990 | Traceback (most recent call last):
  2016-03-10 03:42:39.990 |   File 
"/usr/local/lib/python2.7/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
  2016-03-10 03:42:39.990 | module = self._get_module_from_name(name)
  2016-03-10 03:42:39.990 |   File 
"/usr/local/lib/python2.7/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
  2016-03-10 03:42:39.990 | __import__(name)
  2016-03-10 03:42:39.990 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
 line 21, in 
  2016-03-10 03:42:39.991 | from 
neutron_fwaas.tests.tempest_plugin.tests.scenario import base
  2016-03-10 03:42:39.991 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/base.py",
 line 21, in 
  2016-03-10 03:42:39.991 | from neutron_fwaas.tests.tempest_plugin.tests 
import fwaas_client
  2016-03-10 03:42:39.991 |   File

[Yahoo-eng-team] [Bug 1823716] Re: url --> endpoint_template in Install and configure controller node in neutron section of nova.conf

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1823716

Title:
  url --> endpoint_template in Install and configure controller node in
  neutron section of nova.conf

Status in neutron:
  Fix Released

Bug description:
  https://docs.openstack.org/neutron/rocky/install/controller-install-
  rdo.html says to set url in the [cinder] section of nova.conf.

  But, according to the provided nova.conf template the endpoint_override 
option should be used instead since
  url is deprecated for removal

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1823716/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1828437] Re: Remove unneeded compatibility conversions

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1828437

Title:
  Remove unneeded compatibility conversions

Status in neutron:
  Fix Released

Bug description:
  In order to remove complexity and cleanup the code, those
  compatibility conversions present for more than two releases can be
  removed now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1828437/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1840579] Re: excessive number of dvrs where vm got a fixed ip on floating network

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1840579

Title:
  excessive number of dvrs where vm got a fixed ip on floating network

Status in neutron:
  Fix Released

Bug description:
  we are running into an unexpected situation where number of dvr
  routers is increasing to nearly 2000 on a compute node on which some
  instances got a nic on floating ip network.

  We are using Queens release,

  neutron-common/xenial,now 2:12.0.5-5~u16.04+mcp155 all [installed,automatic]
  neutron-l3-agent/xenial,now 2:12.0.5-5~u16.04+mcp155 all [installed]
  neutron-metadata-agent/xenial,now 2:12.0.5-5~u16.04+mcp155 all 
[installed,automatic]
  neutron-openvswitch-agent/xenial,now 2:12.0.5-5~u16.04+mcp155 all [installed]
  python-neutron/xenial,now 2:12.0.5-5~u16.04+mcp155 all [installed,automatic]
  python-neutron-fwaas/xenial,xenial,now 2:12.0.1-1.0~u16.04+mcp6 all 
[installed,automatic]
  python-neutron-lib/xenial,xenial,now 1.13.0-1.0~u16.04+mcp9 all 
[installed,automatic]
  python-neutronclient/xenial,xenial,now 1:6.7.0-1.0~u16.04+mcp17 all 
[installed,automatic]

  Currently, my guess is that some applications mistakenly invokes rpc
  calls like this
  
https://github.com/openstack/neutron/blob/490471ebd3ac56d0cee164b9c1c1211687e49437/neutron/api/rpc/agentnotifiers/l3_rpc_agent_api.py#L166
  with dvr associated with a floating ip address on a host which has
  fixed ip address allocated from floating network (aka device_owner
  prefix with compute:). Then such router will be kept by this
  
https://github.com/openstack/neutron/blob/490471ebd3ac56d0cee164b9c1c1211687e49437/neutron/db/l3_dvrscheduler_db.py#L427
  function, because `get_subnet_ids_on_router` does not filter out
  router:gateway ports.

  I think this is a bug because as long as we do not have ports with
  specific device owners we should not have a dvr router on it.


  besides it is pretty easy to replay this bug.

  First create a dvr router with an external gateway on floating network
  Then create on virtual machine with fixed ip on floating network
  Then call `routers_updated_on_host` manually, then this dvr will be created 
on the host where vm resides on, but actually it should be there.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1840579/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1844705] Re: Ironic events notifier needs to be migrated from ironicclient to openstacksdk

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1844705

Title:
  Ironic events notifier needs to be migrated from ironicclient to
  openstacksdk

Status in neutron:
  Fix Released

Bug description:
  Ironic events notifier needs to be migrated from ironicclient to
  openstacksdk

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1844705/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1862178] Re: Fullstack tests failing due to "hang" neutron-server process

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1862178

Title:
  Fullstack tests failing due to "hang" neutron-server process

Status in neutron:
  Fix Released

Bug description:
  From time to time some fullstack tests are failing and it seems that the 
problem is with not responding neutron-server process.
  There is almost nothing in neutron-server's logs in such case.

  Example of such failure:
  
https://c355270b22583c2d2af0-42801c5a43c64ea303a559bec7f7cdd7.ssl.cf5.rackcdn.com/705903/2/check/neutron-
  fullstack/79cf197/testr_results.html

  neutron-server logs
  
(https://c355270b22583c2d2af0-42801c5a43c64ea303a559bec7f7cdd7.ssl.cf5.rackcdn.com/705903/2/check/neutron-
  fullstack/79cf197/controller/logs/dsvm-fullstack-
  
logs/TestBwLimitQoSOvs.test_bw_limit_qos_policy_rule_lifecycle_egress_/neutron-
  server--2020-02-05--11-00-19-067345_log.txt) ends on:

  2020-02-05 11:00:36.851 3180 INFO neutron.plugins.ml2.managers 
[req-03044462-4bac-4f8e-acac-d6aae381a3d9 - - - - -] Initializing driver for 
type 'gre'
  2020-02-05 11:00:36.852 3180 INFO neutron.plugins.ml2.drivers.type_tunnel 
[req-03044462-4bac-4f8e-acac-d6aae381a3d9 - - - - -] gre ID ranges: [(1, 1000)]
  2020-02-05 11:00:37.796 3180 INFO neutron.plugins.ml2.managers 
[req-03044462-4bac-4f8e-acac-d6aae381a3d9 - - - - -] Initializing driver for 
type 'local'
  2020-02-05 11:00:37.797 3180 INFO neutron.plugins.ml2.managers 
[req-03044462-4bac-4f8e-acac-d6aae381a3d9 - - - - -] Initializing driver for 
type 'vlan'
  2020-02-05 11:01:11.476 3180 INFO neutron.plugins.ml2.drivers.type_vlan 
[req-03044462-4bac-4f8e-acac-d6aae381a3d9 - - - - -] VlanTypeDriver 
initialization complete
  2020-02-05 11:01:11.479 3180 INFO neutron.plugins.ml2.managers 
[req-03044462-4bac-4f8e-acac-d6aae381a3d9 - - - - -] Initializing driver for 
type 'vxlan'
  2020-02-05 11:01:11.480 3180 INFO neutron.plugins.ml2.drivers.type_tunnel 
[req-03044462-4bac-4f8e-acac-d6aae381a3d9 - - - - -] vxlan ID ranges: [(1001, 
2000)]

  So it seems that it didn't initialize properly ml2 extension drivers
  and mechanism drivers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1862178/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1885695] Re: [OVS] "vsctl" implementation does not allow empty transactions

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1885695

Title:
  [OVS] "vsctl" implementation does not allow empty transactions

Status in neutron:
  Fix Released

Bug description:
  "vsctl" implementation was removed in Train. [1] introduced in Stein a
  bug when using the "vsctl" implementation. A transaction using this
  implementation cannot be empty, should have at least one operation.

  In [2], if qos and queue are None, this transaction won't have any operation. 
As commented, in "vsctl" implementation this will raise the following exception:
Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: missing command name 
(use --help for help)

  **Only stable Stein is affected with this problem.**

  [1]https://review.opendev.org/#/c/738171/
  [2]https://review.opendev.org/#/c/738171/1/neutron/agent/common/ovs_lib.py@914

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1885695/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1885899] Re: test_qos_basic_and_update test is failing

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1885899

Title:
  test_qos_basic_and_update test is failing

Status in neutron:
  Fix Released

Bug description:
  It seems that sometimes nc isn't spawned properly on the guest vm.
  Failure example:
  
https://20f4a85411442f4e3555-9f5a5e2736e26bdd8715596753fafe10.ssl.cf2.rackcdn.com/734876/1/check/neutron-tempest-plugin-scenario-openvswitch/a31f86b/testr_results.html

  Logstash query:
  
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%20%5C%22line%20487%2C%20in%20ensure_nc_listen%5C%22

  
  Traceback:

  Traceback (most recent call last):
File 
"/opt/stack/tempest/.tox/tempest/lib/python3.6/site-packages/neutron_tempest_plugin/scenario/test_qos.py",
 line 263, in test_qos_basic_and_update
  sleep=1)
File 
"/opt/stack/tempest/.tox/tempest/lib/python3.6/site-packages/neutron_tempest_plugin/common/utils.py",
 line 79, in wait_until_true
  while not predicate():
File 
"/opt/stack/tempest/.tox/tempest/lib/python3.6/site-packages/neutron_tempest_plugin/scenario/test_qos.py",
 line 261, in 
  expected_bw=QoSTest.LIMIT_BYTES_SEC * 2),
File 
"/opt/stack/tempest/.tox/tempest/lib/python3.6/site-packages/neutron_tempest_plugin/scenario/test_qos.py",
 line 84, in _check_bw
  self.ensure_nc_listen(ssh_client, port, "tcp")
File 
"/opt/stack/tempest/.tox/tempest/lib/python3.6/site-packages/neutron_tempest_plugin/scenario/base.py",
 line 487, in ensure_nc_listen
  utils.wait_until_true(spawn_and_check_process)
File 
"/opt/stack/tempest/.tox/tempest/lib/python3.6/site-packages/neutron_tempest_plugin/common/utils.py",
 line 85, in wait_until_true
  raise WaitTimeout("Timed out after %d seconds" % timeout)
  neutron_tempest_plugin.common.utils.WaitTimeout: Timed out after 60 seconds

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1885899/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1887992] Re: [neutron-tempest-plugin] glance service failing during the installation

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1887992

Title:
  [neutron-tempest-plugin] glance service failing during the
  installation

Status in neutron:
  Fix Released

Bug description:
  In some neutron-tempest-plugin CI jobs, "glance" service is not starting:
  
https://133eaf5aa1613130d74d-11eee2f9a8da0aa272aa38b865c1ef08.ssl.cf5.rackcdn.com/715482/15/check/neutron-tempest-plugin-api/9c57856/job-output.txt

  Error:
  [ERROR] /opt/stack/devstack/lib/glance:361 g-api did not start

  That could be caused because of a recent patch in devstack:
  https://review.opendev.org/#/c/741258

  According to the owner, that should be fixed with
  https://review.opendev.org/#/c/741687

  In those jobs, the service "tls-proxy" is disabled:
  https://github.com/openstack/neutron-tempest-
  plugin/blob/master/zuul.d/base.yaml

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1887992/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1895196] Re: pecan>=1.4.0 is greater than upper-constraints.txt

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1895196

Title:
  pecan>=1.4.0 is greater than upper-constraints.txt

Status in neutron:
  Fix Released

Bug description:
  The pecan min version in requirements.txt is higher than upper-
  constraints.

  upper-constraints.txt currently has:
  pecan===1.3.3

  https://github.com/openstack/requirements/blob/master/upper-
  constraints.txt

  but requirements.txt in neutron has:
  pecan>=1.4.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1895196/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1908711] Re: [neutron-lib] Bump PyYAML to 5.3.1

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1908711

Title:
  [neutron-lib] Bump PyYAML to 5.3.1

Status in neutron:
  Fix Released

Bug description:
  This is the minimum version required by bandit>=1.6.3, that is the
  minimum version installed by this library.

  LOG:
  
https://629fe5679f8dfd9396e8-e24395b1f226ab7bf437be1dd808e069.ssl.cf2.rackcdn.com/767586/2/check/openstack-
  tox-lower-constraints/456ed34/job-output.txt

  Snippet: http://paste.openstack.org/show/801148/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1908711/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1910717] Re: "test_set_igmp_snooping_flood" fails because "ports_other_config" is None

** Tags removed: neutron-proactive-backport-potential

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1910717

Title:
  "test_set_igmp_snooping_flood" fails because "ports_other_config" is
  None

Status in neutron:
  Fix Released

Bug description:
  "test_set_igmp_snooping_flood" fails because "ports_other_config" is
  None after being set in the previous line.

self.ovs.set_igmp_snooping_flood(port_name, True)
ports_other_config = self.ovs.db_get_val('Port', port_name, 'other_config')

  Log:
  
https://b03ae727f46a68c51347-58d582b1ad987403ec8ac78ac19177df.ssl.cf5.rackcdn.com/769880/1/check/neutron-
  functional-with-uwsgi/157d413/testr_results.html

  Snippet: http://paste.openstack.org/show/801508/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1910717/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1915310] Re: Resource name and collection name for address groups are incorrectly defined in neutron-lib

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1915310

Title:
  Resource name and collection name for address groups are incorrectly
  defined in  neutron-lib

Status in neutron:
  Fix Released

Bug description:
  RESOURCE_NAME and COLLECTION_NAME are incorrectly defined in neutron-
  lib: https://github.com/openstack/neutron-
  
lib/blob/2dabcc5cf7d68bf2a4640f07d5e170aa8b911390/neutron_lib/api/definitions/address_group.py#L25-L26

  Their definitions should have '_' instead of '-'. This incorrect
  definition prevents the proper setup in policy FieldCheck, which uses
  the policy engine match to look for the resource in the API attributes
  table:
  
https://github.com/openstack/neutron/blob/a3dc80b509d72c8d1a3ea007cb657a9e217ba66a/neutron/policy.py#L359-L377

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1915310/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1918274] Re: Driver VLAN do not create the VlanAllocation registers if "network_vlan_ranges" only specify the network

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1918274

Title:
  Driver VLAN do not create the VlanAllocation registers if
  "network_vlan_ranges" only specify the network

Status in neutron:
  Fix Released

Bug description:
  "network_vlan_ranges" allows to define a list of physical networks and
  VLAN ranges [1]. But is possible to just define the physical network
  without the VLAN ID ranges; in that case, the VLAN driver should take
  all valid VLAN IDs (from 1 to 4094).

  If no VLAN range is defined, when "VlanTypeDriver._sync_vlan_allocations" is 
called, the "ranges" variable is:
ranges = {'physical_net': []}

  We have two options here:
  - Modify the sync method.
  - Change the parser to populate, in case of not passing any VLAN range, the 
whole list of possible VLAN IDs for this physnet (I think last option is 
better).

  
[1]https://github.com/openstack/neutron/blob/ab78d29c68b3cfdc6732d2ed2bcec0677b1a34f3/neutron/conf/plugins/ml2/drivers/driver_type.py#L68-L76

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1918274/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1726434] Re: delete router from horizon causes critical error in neutron logs

** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1726434

Title:
  delete router from horizon causes critical error in neutron logs

Status in neutron:
  Fix Released

Bug description:
  While deleting a router from the horizon interface the following error
  is observed in the neutron-agent-container.

  root@infra1-neutron-agents-container-efc7805b:~# tail -45 
/var/log/neutron/neutron.log
  2017-10-23 17:12:15.472 20348 DEBUG neutron.agent.linux.utils [-] Running 
command: ['sudo', '/openstack/venvs/neutron-16.0.1/bin/neutron-rootwrap', 
'/etc/neutron/rootwrap.conf', 'kill', '-9', '20349'] create_process 
/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/neutron/agent/linux/utils.py:92
  2017-10-23 17:12:15.488 20348 CRITICAL neutron [-] Unhandled error: 
AssertionError: do not call blocking functions from the mainloop
  2017-10-23 17:12:15.488 20348 ERROR neutron Traceback (most recent call last):
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/bin/neutron-keepalived-state-change", line 11, 
in 
  2017-10-23 17:12:15.488 20348 ERROR neutron sys.exit(main())
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/neutron/cmd/keepalived_state_change.py",
 line 19, in main
  2017-10-23 17:12:15.488 20348 ERROR neutron keepalived_state_change.main()
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/neutron/agent/l3/keepalived_state_change.py",
 line 156, in main
  2017-10-23 17:12:15.488 20348 ERROR neutron cfg.CONF.monitor_cidr).start()
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/neutron/agent/linux/daemon.py",
 line 253, in start
  2017-10-23 17:12:15.488 20348 ERROR neutron self.run()
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/neutron/agent/l3/keepalived_state_change.py",
 line 69, in run
  2017-10-23 17:12:15.488 20348 ERROR neutron for iterable in self.monitor:
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/neutron/agent/linux/async_process.py",
 line 261, in _iter_queue
  2017-10-23 17:12:15.488 20348 ERROR neutron yield queue.get(block=block)
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/eventlet/queue.py",
 line 313, in get
  2017-10-23 17:12:15.488 20348 ERROR neutron return waiter.wait()
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/eventlet/queue.py",
 line 141, in wait
  2017-10-23 17:12:15.488 20348 ERROR neutron return get_hub().switch()
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/eventlet/hubs/hub.py",
 line 294, in switch
  2017-10-23 17:12:15.488 20348 ERROR neutron return self.greenlet.switch()
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/eventlet/hubs/hub.py",
 line 346, in run
  2017-10-23 17:12:15.488 20348 ERROR neutron self.wait(sleep_time)
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/eventlet/hubs/poll.py",
 line 85, in wait
  2017-10-23 17:12:15.488 20348 ERROR neutron presult = 
self.do_poll(seconds)
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/eventlet/hubs/epolls.py",
 line 62, in do_poll
  2017-10-23 17:12:15.488 20348 ERROR neutron return self.poll.poll(seconds)
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/neutron/agent/l3/keepalived_state_change.py",
 line 133, in handle_sigterm
  2017-10-23 17:12:15.488 20348 ERROR neutron self._kill_monitor()
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/neutron/agent/l3/keepalived_state_change.py",
 line 130, in _kill_monitor
  2017-10-23 17:12:15.488 20348 ERROR neutron run_as_root=True)
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/neutron/agent/linux/utils.py",
 line 223, in kill_process
  2017-10-23 17:12:15.488 20348 ERROR neutron execute(['kill', '-%d' % 
signal, pid], run_as_root=run_as_root)
  2017-10-23 17:12:15.488 20348 ERROR neutron   File 
"/openstack/venvs/neutron-16.0.1/lib/python2.7/site-packages/neutron/agent/linux/utils.py",
 line 131, in execute
  2017-10-23 17:12:15.488 20348 ERROR neutron

[Yahoo-eng-team] [Bug 1824477] Re: dhcp: need to reorder classless static route record