[Yahoo-eng-team] [Bug 1526642] [NEW] Simultaneous live migrations break anti-affinity policy
Public bug reported: Let's say we have a setup with 3 compute nodes (CN1, CN2 and CN3) and 3 controllers (in HA mode). There are 2 VMs with anti-affinity policy (the same server group) running in the environment: * CN1 - VM A (anti-affinity) * CN2 - VM B (anti-affinity) * CN3 - empty If we trigger live migration of VM A and then trigger live migration of VM B without waiting for scheduling phase of VM A to complete we will end up with anti-affinity policy violated: * CN1 - empty * CN2 - empty * CN3 - VM A, VM B (both with anti-affinity policy) Workaround is to wait few seconds and let scheduler finish the job for the first VM. ** Affects: nova Importance: Undecided Status: New ** Tags: anti-affinity live-migration scheduler -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1526642 Title: Simultaneous live migrations break anti-affinity policy Status in OpenStack Compute (nova): New Bug description: Let's say we have a setup with 3 compute nodes (CN1, CN2 and CN3) and 3 controllers (in HA mode). There are 2 VMs with anti-affinity policy (the same server group) running in the environment: * CN1 - VM A (anti-affinity) * CN2 - VM B (anti-affinity) * CN3 - empty If we trigger live migration of VM A and then trigger live migration of VM B without waiting for scheduling phase of VM A to complete we will end up with anti-affinity policy violated: * CN1 - empty * CN2 - empty * CN3 - VM A, VM B (both with anti-affinity policy) Workaround is to wait few seconds and let scheduler finish the job for the first VM. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1526642/+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 1526641] [NEW] Invalid metadata value to location-add causing 500 Internal Server Error
Public bug reported: Passing invalid metadata value to location-add or location-update command raises 500 Internal Server Error. 1. glance location-add --url http://10.69.4.136:8111/run_tests.sh --metadata '{"a":1234}' or 2. glance location-update --url http://10.69.4.136:8111/run_tests.sh --metadata '{"a":1234}' Stacktrace on g-api: 2015-12-15 03:47:49.876 ERROR glance.common.wsgi [req-3a349a22-8b69-40bf-93f1-6388eb5cb4ee 6c9c7376e75b4e37ab3c052a911731dd d1ee7fd5dcc341c3973f19f790238e63] Caught error: The image metadata key a has an invalid type of . Only dict, list, and unicode are supported. 2015-12-15 03:47:49.876 TRACE glance.common.wsgi Traceback (most recent call last):2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/common/wsgi.py", line 882, in __call__ 2015-12-15 03:47:49.876 TRACE glance.common.wsgi request, **action_args) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/common/wsgi.py", line 911, in dispatch 2015-12-15 03:47:49.876 TRACE glance.common.wsgi return method(*args, **kwargs) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/common/utils.py", line 423, in wrapped 2015-12-15 03:47:49.876 TRACE glance.common.wsgi return func(self, req, *args,**kwargs) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/api/v2/images.py", line 147, in update 2015-12-15 03:47:49.876 TRACE glance.common.wsgi change_method(req, image, change) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/api/v2/images.py", line 197, in _do_add 2015-12-15 03:47:49.876 TRACE glance.common.wsgi self._do_add_locations(image, path[1], value) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/api/v2/images.py", line 292, in _do_add_locations 2015-12-15 03:47:49.876 TRACE glance.common.wsgi image.locations.insert(pos, value) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/api/policy.py", line 275, in _checker 2015-12-15 03:47:49.876 TRACE glance.common.wsgi return method(*args, **kwargs) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/quota/__init__.py", line 273, in insert 2015-12-15 03:47:49.876 TRACE glance.common.wsgi return self.locations.insert(index, object) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/location.py", line 179, in insert 2015-12-15 03:47:49.876 TRACE glance.common.wsgi location) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/location.py", line 91, in _check_image_location 2015-12-15 03:47:49.876 TRACE glance.common.wsgi store_api.check_location_metadata(location['metadata']) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/usr/local/lib/python2.7/dist-packages/glance_store/backend.py", line 309, in check_location_metadata 2015-12-15 03:47:49.876 TRACE glance.common.wsgi check_location_metadata(val[key], key=key) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/usr/local/lib/python2.7/dist-packages/glance_store/backend.py", line 320, in check_location_metadata 2015-12-15 03:47:49.876 TRACE glance.common.wsgi % dict(key=key, type=type(val))) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi BackendException: The image metadata key a has an invalid type of . Only dict, list, and unicode are supported. 2015-12-15 03:47:49.876 TRACE glance.common.wsgi ** Affects: glance Importance: Undecided Assignee: Abhishek Kekane (abhishek-kekane) Status: New ** Changed in: glance Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1526641 Title: Invalid metadata value to location-add causing 500 Internal Server Error Status in Glance: New Bug description: Passing invalid metadata value to location-add or location-update command raises 500 Internal Server Error. 1.glance location-add --url http://10.69.4.136:8111/run_tests.sh --metadata '{"a":1234}' or 2.glance location-update --url http://10.69.4.136:8111/run_tests.sh --metadata '{"a":1234}' Stacktrace on g-api: 2015-12-15 03:47:49.876 ERROR glance.common.wsgi [req-3a349a22-8b69-40bf-93f1-6388eb5cb4ee 6c9c7376e75b4e37ab3c052a911731dd d1ee7fd5dcc341c3973f19f790238e63] Caught error: The image metadata key a has an invalid type of . Only dict, list, and unicode are supported. 2015-12-15 03:47:49.876 TRACE glance.common.wsgi Traceback (most recent call last):2015-12-15 03:47:49.876 TRACE glance.common.wsgi File "/opt/stack/glance/glance/common/wsgi.py", line 882, in __call__ 2015-12-15 03:47:49.876 TRACE glance.common.wsgi request, **action_args) 2015-12-15 03:47:49.876 TRACE glance.common.wsgi
[Yahoo-eng-team] [Bug 1526644] [NEW] availability zones code issuing query for every router
Public bug reported: the router availability zone code suffers from the same problem described in https://bugs.launchpad.net/neutron/+bug/1525740 but for router listing instead of network listing. This degrades the response time of router list operations. ** Affects: neutron Importance: High Assignee: Kevin Benton (kevinbenton) Status: New ** Changed in: neutron Assignee: (unassigned) => Kevin Benton (kevinbenton) ** Description changed: the router availability zone code suffers from the same problem described in https://bugs.launchpad.net/neutron/+bug/1525740 but for router listing instead of network listing. + + This degrades the response time of router list operations. ** Changed in: neutron Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1526644 Title: availability zones code issuing query for every router Status in neutron: New Bug description: the router availability zone code suffers from the same problem described in https://bugs.launchpad.net/neutron/+bug/1525740 but for router listing instead of network listing. This degrades the response time of router list operations. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1526644/+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 1526637] [NEW] test for git review,ignore it
Public bug reported: test for git review,ignore it ** Affects: keystone Importance: Undecided Assignee: liuhui (leoson) Status: New ** Changed in: keystone Assignee: (unassigned) => liuhui (leoson) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1526637 Title: test for git review,ignore it Status in OpenStack Identity (keystone): New Bug description: test for git review,ignore it To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1526637/+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 1525740] Re: network availability zone code causes lookups for every network
Reviewed: https://review.openstack.org/257086 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=57964df5c6e4d590516ae7eb1783f694fa24f501 Submitter: Jenkins Branch:master commit 57964df5c6e4d590516ae7eb1783f694fa24f501 Author: Kevin Benton Date: Sun Dec 13 17:56:57 2015 -0800 Use a joined relationship for AZ info on networks The previous code was doing a DB lookup for each network's availability zone which was significantly impacting the performance of network listings. This patch adjusts the network model to be automatically joined to the DHCP agents table that the AZ code uses to populate the AZs for the network. Change-Id: I908ceb1a68e0eed7c304e3ff82279ad6fa406167 Closes-Bug: #1525740 ** Changed in: neutron Status: In Progress => 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/1525740 Title: network availability zone code causes lookups for every network Status in neutron: Fix Released Bug description: the code to populate network info with availability zone info is causing a database lookup in every network dictionary extend function. This causes a major regression in network listing performance by doing 1 DB call per database. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525740/+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 1526630] [NEW] Unexpected API Error returned when boot an instance with an wrong octal ip address as v4-fixed-ip
Public bug reported: [Summary] Unexpected API Error returned when boot an instance with an wrong octal ip address as v4-fixed-ip [Topo] devstack all-in-one node [Description and expect result] no Unexpected API Error, should return an error says that "Invalid input for field/attribute fixed_ip" [Reproduceable or not] reproduceable [Recreate Steps] 1) create a network/subnet: root@45-59:/opt/stack/devstack# neutron net-list | grep net2 | 2de63c95-f645-492c-9197-5d4d5244a8ba | net2| 47eb5e03-c16a-4303-923c-21a061f2909e 1.0.0.0/24 | root@45-59:/opt/stack/devstack# 2) launch an instance with an wrong octal ip address as v4-fixed-ip, Unexpected API Error returned: ISSUE root@45-59:/opt/stack/devstack# nova boot --flavor 1 --image cirros-0.3.4-x86_64-uec --availability-zone nova --nic net-id=2de63c95-f645-492c-9197- 5d4d5244a8ba,v4-fixed-ip=1.0.0.087 inst2 ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-17cc4e5a-af9f-44b9-9c4a-b87706682bf3) root@45-59:/opt/stack/devstack# Note: 1.0.0.087 is an ip address in octal format, but it's a wrong address, octal address can not contain number character bigger than 7. [Configration] reproduceable bug, no need [logs] reproduceable bug, no need [Root cause anlyze or debug inf] reproduceable bug [Attachment] None ** Affects: nova Importance: Undecided Assignee: hgan...@cn.ibm.com (hgangwx) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1526630 Title: Unexpected API Error returned when boot an instance with an wrong octal ip address as v4-fixed-ip Status in OpenStack Compute (nova): New Bug description: [Summary] Unexpected API Error returned when boot an instance with an wrong octal ip address as v4-fixed-ip [Topo] devstack all-in-one node [Description and expect result] no Unexpected API Error, should return an error says that "Invalid input for field/attribute fixed_ip" [Reproduceable or not] reproduceable [Recreate Steps] 1) create a network/subnet: root@45-59:/opt/stack/devstack# neutron net-list | grep net2 | 2de63c95-f645-492c-9197-5d4d5244a8ba | net2| 47eb5e03-c16a-4303-923c-21a061f2909e 1.0.0.0/24 | root@45-59:/opt/stack/devstack# 2) launch an instance with an wrong octal ip address as v4-fixed-ip, Unexpected API Error returned: ISSUE root@45-59:/opt/stack/devstack# nova boot --flavor 1 --image cirros-0.3.4-x86_64-uec --availability-zone nova --nic net-id=2de63c95-f645-492c-9197- 5d4d5244a8ba,v4-fixed-ip=1.0.0.087 inst2 ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-17cc4e5a-af9f-44b9-9c4a-b87706682bf3) root@45-59:/opt/stack/devstack# Note: 1.0.0.087 is an ip address in octal format, but it's a wrong address, octal address can not contain number character bigger than 7. [Configration] reproduceable bug, no need [logs] reproduceable bug, no need [Root cause anlyze or debug inf] reproduceable bug [Attachment] None To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1526630/+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 1526620] [NEW] host names are different even if scheduling servers on the same host
Public bug reported: Even if creating a server with scheduler_hint: same_host, the server is created on different host on the gate. 'OS-EXT-SRV-ATTR:host' value of "show a server" API is different between servers like: * ubuntu-trusty-2-node-rax-iad-6591881 * ubuntu-trusty-2-node-rax-iad-6591881-77157 Now we are trying to add Tempest test for verifying the scheduler_hint on https://review.openstack.org/#/c/257660 However the test cannot be passed due to this problem. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1526620 Title: host names are different even if scheduling servers on the same host Status in OpenStack Compute (nova): New Bug description: Even if creating a server with scheduler_hint: same_host, the server is created on different host on the gate. 'OS-EXT-SRV-ATTR:host' value of "show a server" API is different between servers like: * ubuntu-trusty-2-node-rax-iad-6591881 * ubuntu-trusty-2-node-rax-iad-6591881-77157 Now we are trying to add Tempest test for verifying the scheduler_hint on https://review.openstack.org/#/c/257660 However the test cannot be passed due to this problem. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1526620/+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 1526611] [NEW] integration test timeout on every run
Public bug reported: While attempting to run the integration test suite locally on my OS X system against a remote devstack I repeatable encountered the following timeout: _StringException: Traceback (most recent call last): File ".../src/openstack/horizon/openstack_dashboard/test/integration_tests/tests/test_login.py", line 25, in test_login login_pg.go_to_login_page() File ".../src/openstack/horizon/openstack_dashboard/test/integration_tests/pages/pageobject.py", line 79, in go_to_login_page self.driver.get(self.login_url) File ".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 213, in get self.execute(Command.GET, url': url}) File ".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 199, in execute response = self.command_executor.execute(driver_command, params) File ".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py", line 395, in execute return self._request(command_info[0], url, body=data) File ".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py", line 426, in _request resp = self._conn.getresponse() File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 1073, in getresponse response.begin() File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 415, in begin version, status, reason = self._read_status() File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 371, in _read_status line = self.fp.readline(_MAXLINE + 1) File ".../.pyenv/versions/2.7.9/lib/python2.7/socket.py", line 476, in readline data = self._sock.recv(self._rbufsize) socket.timeout: timed out This is in the communication channel between the test process and the selenium webdriver process. I get it every time I attempt to run a test. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1526611 Title: integration test timeout on every run Status in OpenStack Dashboard (Horizon): New Bug description: While attempting to run the integration test suite locally on my OS X system against a remote devstack I repeatable encountered the following timeout: _StringException: Traceback (most recent call last): File ".../src/openstack/horizon/openstack_dashboard/test/integration_tests/tests/test_login.py", line 25, in test_login login_pg.go_to_login_page() File ".../src/openstack/horizon/openstack_dashboard/test/integration_tests/pages/pageobject.py", line 79, in go_to_login_page self.driver.get(self.login_url) File ".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 213, in get self.execute(Command.GET, url': url}) File ".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 199, in execute response = self.command_executor.execute(driver_command, params) File ".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py", line 395, in execute return self._request(command_info[0], url, body=data) File ".../src/openstack/horizon/.venv/lib/python2.7/site-packages/selenium/webdriver/remote/remote_connection.py", line 426, in _request resp = self._conn.getresponse() File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 1073, in getresponse response.begin() File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 415, in begin version, status, reason = self._read_status() File ".../.pyenv/versions/2.7.9/lib/python2.7/httplib.py", line 371, in _read_status line = self.fp.readline(_MAXLINE + 1) File ".../.pyenv/versions/2.7.9/lib/python2.7/socket.py", line 476, in readline data = self._sock.recv(self._rbufsize) socket.timeout: timed out This is in the communication channel between the test process and the selenium webdriver process. I get it every time I attempt to run a test. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1526611/+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 1526607] [NEW] refactor test_attributes.py
Public bug reported: there're many test methods contains repeated test cases, such as def test_validate_string(self): msg = attributes._validate_string(None, None) self.assertEqual("'None' is not a valid string", msg) # 0 == len(data) == max_len msg = attributes._validate_string("", 0) self.assertIsNone(msg) # 0 == len(data) < max_len msg = attributes._validate_string("", 9) self.assertIsNone(msg) # 0 < len(data) < max_len msg = attributes._validate_string("123456789", 10) self.assertIsNone(msg) # 0 < len(data) == max_len msg = attributes._validate_string("123456789", 9) self.assertIsNone(msg) # 0 < max_len < len(data) msg = attributes._validate_string("1234567890", 9) self.assertEqual("'1234567890' exceeds maximum length of 9", msg) msg = attributes._validate_string("123456789", None) self.assertIsNone(msg) we can refactor this with a for loop, to make them look better ** Affects: neutron Importance: Undecided Assignee: Bo Chi (bochi-michael) Status: New ** Changed in: neutron Assignee: (unassigned) => Bo Chi (bochi-michael) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1526607 Title: refactor test_attributes.py Status in neutron: New Bug description: there're many test methods contains repeated test cases, such as def test_validate_string(self): msg = attributes._validate_string(None, None) self.assertEqual("'None' is not a valid string", msg) # 0 == len(data) == max_len msg = attributes._validate_string("", 0) self.assertIsNone(msg) # 0 == len(data) < max_len msg = attributes._validate_string("", 9) self.assertIsNone(msg) # 0 < len(data) < max_len msg = attributes._validate_string("123456789", 10) self.assertIsNone(msg) # 0 < len(data) == max_len msg = attributes._validate_string("123456789", 9) self.assertIsNone(msg) # 0 < max_len < len(data) msg = attributes._validate_string("1234567890", 9) self.assertEqual("'1234567890' exceeds maximum length of 9", msg) msg = attributes._validate_string("123456789", None) self.assertIsNone(msg) we can refactor this with a for loop, to make them look better To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1526607/+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 1490497] Re: pep8-incompliant filenames missing in gate console logs
[Expired for hacking because there has been no activity for 60 days.] ** Changed in: hacking Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1490497 Title: pep8-incompliant filenames missing in gate console logs Status in hacking: Expired Status in OpenStack Identity (keystone): Invalid Bug description: Jenkins reported gate-keystone-pep8 failure on patch set 12 @ https://review.openstack.org/#/c/209524/ . But the console logs didn't contain the filenames that are incompliant with pep8. http://logs.openstack.org/24/209524/12/check/gate-keystone-pep8/b2b7500/console.html ... 2015-08-30 22:34:11.101 | pep8 runtests: PYTHONHASHSEED='3894393079' 2015-08-30 22:34:11.102 | pep8 runtests: commands[0] | flake8 2015-08-30 22:34:11.102 | /home/jenkins/workspace/gate-keystone-pep8$ /home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8 2015-08-30 22:34:16.619 | ERROR: InvocationError: '/home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8' 2015-08-30 22:34:16.620 | ___ summary 2015-08-30 22:34:16.620 | ERROR: pep8: commands failed ... Typically, it contains the filenames as well. Eg. Console logs pf patchset 1 contains the filenames. http://logs.openstack.org/24/209524/1/check/gate-keystone-pep8/19f2885/console.html ... 2015-08-05 14:45:15.247 | pep8 runtests: PYTHONHASHSEED='1879982710' 2015-08-05 14:45:15.247 | pep8 runtests: commands[0] | flake8 2015-08-05 14:45:15.247 | /home/jenkins/workspace/gate-keystone-pep8$ /home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8 2015-08-05 14:45:20.518 | ./keystone/assignment/backends/ldap.py:37:5: E301 expected 1 blank line, found 0 2015-08-05 14:45:20.518 | @versionutils.deprecated( 2015-08-05 14:45:20.518 | ^ ... 2015-08-05 14:45:20.872 | ERROR: InvocationError: '/home/jenkins/workspace/gate-keystone-pep8/.tox/pep8/bin/flake8' 2015-08-05 14:45:20.872 | ___ summary 2015-08-05 14:45:20.873 | ERROR: pep8: commands failed ... To manage notifications about this bug go to: https://bugs.launchpad.net/hacking/+bug/1490497/+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 1506567] Re: No information from Neutron Metering agent
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1506567 Title: No information from Neutron Metering agent Status in neutron: Expired Bug description: I deployed OpenStack cloud with stable/kilo code - a controller/network node and a compute node (Ubuntu 14.04). I have Metering agent enabled and configured as follows: driver = neutron.services.metering.drivers.iptables.iptables_driver.IptablesMeteringDriver interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver When I try to check information from it in Ceilometer, I always get zero. e.x.: root@node-1:~# ceilometer sample-list -m bandwidth -l10 +--+---+---++--++ | Resource ID | Name | Type | Volume | Unit | Timestamp | +--+---+---++--++ | 66fab4a9-aefe-4534-b8a3-b0c0db9edf82 | bandwidth | delta | 0.0| B| 2015-10-15T16:55:26.766000 | Is it expected? I spawned two VMs and tried to pass some traffic between them using iperf, but still no results To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1506567/+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 1506566] Re: no notifications from Neutron in Ceilometer
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1506566 Title: no notifications from Neutron in Ceilometer Status in neutron: Expired Bug description: I've deployed devstack using the following local.conf (with Ceilometer) - http://paste.openstack.org/show/476407/ (master branch) After deployment I tried to check Ceilometer notifications and get nothing from Neutron. For example, I created a router and then executed ceilometer sample-list -m router.create -l10 - got nothing. Is something misconfigured? Also there's no information from Neutron metering agent regarding bandwidth. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1506566/+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 1526599] [NEW] back-port of oslo import to stable kilo is not enough
Public bug reported: Back-port of oslo import to stable kilo is not enough and caused Devstack installation failed. [Error message example] 2015-12-16 02:41:08.120 | + cd /opt/stack/horizon 2015-12-16 02:41:08.120 | + ./run_tests.sh -N --compilemessages 2015-12-16 02:41:08.604 | WARNING:root:No local_settings file found. 2015-12-16 02:41:09.019 | Traceback (most recent call last): 2015-12-16 02:41:09.019 | File "/opt/stack/horizon/manage.py", line 23, in 2015-12-16 02:41:09.019 | execute_from_command_line(sys.argv) 2015-12-16 02:41:09.019 | File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 354, in execute_from_command_line 2015-12-16 02:41:09.020 | utility.execute() 2015-12-16 02:41:09.020 | File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 303, in execute 2015-12-16 02:41:09.020 | settings.INSTALLED_APPS 2015-12-16 02:41:09.020 | File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in __getattr__ 2015-12-16 02:41:09.020 | self._setup(name) 2015-12-16 02:41:09.020 | File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in _setup 2015-12-16 02:41:09.020 | self._wrapped = Settings(settings_module) 2015-12-16 02:41:09.020 | File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 92, in __init__ 2015-12-16 02:41:09.021 | mod = importlib.import_module(self.SETTINGS_MODULE) 2015-12-16 02:41:09.021 | File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module 2015-12-16 02:41:09.021 | __import__(name) 2015-12-16 02:41:09.021 | File "/opt/stack/horizon/openstack_dashboard/settings.py", line 313, in 2015-12-16 02:41:09.021 | from openstack_dashboard import policy_backend 2015-12-16 02:41:09.021 | File "/opt/stack/horizon/openstack_dashboard/policy_backend.py", line 23, in 2015-12-16 02:41:09.021 | from openstack_dashboard.openstack.common import policy 2015-12-16 02:41:09.021 | File "/opt/stack/horizon/openstack_dashboard/openstack/common/policy.py", line 83, in 2015-12-16 02:41:09.021 | from oslo.config import cfg 2015-12-16 02:41:09.022 | ImportError: No module named config ** Affects: horizon Importance: Undecided Status: New ** Tags: kilo-backport-potential -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1526599 Title: back-port of oslo import to stable kilo is not enough Status in OpenStack Dashboard (Horizon): New Bug description: Back-port of oslo import to stable kilo is not enough and caused Devstack installation failed. [Error message example] 2015-12-16 02:41:08.120 | + cd /opt/stack/horizon 2015-12-16 02:41:08.120 | + ./run_tests.sh -N --compilemessages 2015-12-16 02:41:08.604 | WARNING:root:No local_settings file found. 2015-12-16 02:41:09.019 | Traceback (most recent call last): 2015-12-16 02:41:09.019 | File "/opt/stack/horizon/manage.py", line 23, in 2015-12-16 02:41:09.019 | execute_from_command_line(sys.argv) 2015-12-16 02:41:09.019 | File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 354, in execute_from_command_line 2015-12-16 02:41:09.020 | utility.execute() 2015-12-16 02:41:09.020 | File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 303, in execute 2015-12-16 02:41:09.020 | settings.INSTALLED_APPS 2015-12-16 02:41:09.020 | File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in __getattr__ 2015-12-16 02:41:09.020 | self._setup(name) 2015-12-16 02:41:09.020 | File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in _setup 2015-12-16 02:41:09.020 | self._wrapped = Settings(settings_module) 2015-12-16 02:41:09.020 | File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 92, in __init__ 2015-12-16 02:41:09.021 | mod = importlib.import_module(self.SETTINGS_MODULE) 2015-12-16 02:41:09.021 | File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module 2015-12-16 02:41:09.021 | __import__(name) 2015-12-16 02:41:09.021 | File "/opt/stack/horizon/openstack_dashboard/settings.py", line 313, in 2015-12-16 02:41:09.021 | from openstack_dashboard import policy_backend 2015-12-16 02:41:09.021 | File "/opt/stack/horizon/openstack_dashboard/policy_backend.py", line 23, in 2015-12-16 02:41:09.021 | from openstack_dashboard.openstack.common import policy 2015-12-16 02:41:09.021 | File "/opt/stack/horizon/openstack_dashboard/openstack/common/policy.py", line 83, in 2015-12-16 02:41:09.021 | from oslo.config import cfg 2015-12-16 02:41:09.022 | ImportError: No module named config To manage notifications about this bug go to: h
[Yahoo-eng-team] [Bug 1526587] [NEW] Neutron doesn't have a command to show the available ports for one subnet
Public bug reported: Neutron doesn't have a command to show the available ports for one subnet. We can get the available port list with command: [root@cts-orch ~]# neutron port-list | grep `neutron subnet-show 110-OAM2 | awk '/ id / {print $4}'` | cut -d"|" -f5 | cut -d":" -f3 | sort "135.111.122.97"} "135.111.122.98"} But we don't have a command to show the available ports for one subnet. I write a shell script to show the available ports as below, but it will be helpful if we can provide such a neutron command. [root@cts-orch ~]# ./show_available_ip.sh 110-OAM2 135.111.122.99 135.111.122.100 135.111.122.101 135.111.122.102 135.111.122.103 135.111.122.104 135.111.122.105 135.111.122.106 135.111.122.107 135.111.122.108 135.111.122.109 135.111.122.110 135.111.122.111 135.111.122.112 135.111.122.113 135.111.122.114 135.111.122.115 135.111.122.116 135.111.122.117 135.111.122.118 135.111.122.119 135.111.122.120 135.111.122.121 135.111.122.122 135.111.122.123 135.111.122.124 Total Count: 26 ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1526587 Title: Neutron doesn't have a command to show the available ports for one subnet Status in neutron: New Bug description: Neutron doesn't have a command to show the available ports for one subnet. We can get the available port list with command: [root@cts-orch ~]# neutron port-list | grep `neutron subnet-show 110-OAM2 | awk '/ id / {print $4}'` | cut -d"|" -f5 | cut -d":" -f3 | sort "135.111.122.97"} "135.111.122.98"} But we don't have a command to show the available ports for one subnet. I write a shell script to show the available ports as below, but it will be helpful if we can provide such a neutron command. [root@cts-orch ~]# ./show_available_ip.sh 110-OAM2 135.111.122.99 135.111.122.100 135.111.122.101 135.111.122.102 135.111.122.103 135.111.122.104 135.111.122.105 135.111.122.106 135.111.122.107 135.111.122.108 135.111.122.109 135.111.122.110 135.111.122.111 135.111.122.112 135.111.122.113 135.111.122.114 135.111.122.115 135.111.122.116 135.111.122.117 135.111.122.118 135.111.122.119 135.111.122.120 135.111.122.121 135.111.122.122 135.111.122.123 135.111.122.124 Total Count: 26 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1526587/+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 1490804] Re: PKI Token Revocation Bypass (CVE-2015-7546)
This issue has been published as OSSN-0062: https://wiki.openstack.org/wiki/OSSN/OSSN-0062 ** Changed in: ossn Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1490804 Title: PKI Token Revocation Bypass (CVE-2015-7546) Status in django-openstack-auth: Invalid Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in OpenStack Security Advisory: Incomplete Status in OpenStack Security Notes: Fix Released Status in python-keystoneclient: Won't Fix Bug description: A keystone token which has been revoked can still be used by manipulating particular byte fields within the token. When a Keystone token is revoked it is added to the revoked list which stores the exact token value. Any API will look at the token to see whether or not it should accept a token. By changing a single byte within the token, the revocation can be bypassed. see the testing script [1]. It is suggested that the revocation should be changed to only check the token's inner ID. [1] http://paste.openstack.org/show/436516/ To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1490804/+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 1462694] Re: python keystone v3 client RoleAssignmentManager needs to pass include_subtree
Reviewed: https://review.openstack.org/188184 Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=7ff3955665b64e59db8bf1668ae5d7839bb6b730 Submitter: Jenkins Branch:master commit 7ff3955665b64e59db8bf1668ae5d7839bb6b730 Author: daniel-a-nguyen Date: Wed Jun 3 14:39:34 2015 -0700 Add include_subtree to role_list_assignments call This is needed for Domain Admin to list role assignments. Related-Bug: 1437407 Depends-On: I3495c7cab3b40811b2722ac7d70ddda30410b62b Closes-Bug: #1462694 Change-Id: I63849d5f39d090fec3ef6b9182f339e198e0c551 ** Changed in: python-keystoneclient Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1462694 Title: python keystone v3 client RoleAssignmentManager needs to pass include_subtree Status in OpenStack Identity (keystone): Invalid Status in python-keystoneclient: Fix Released Bug description: In order for a Domain Admin to successfully list the role assignments in the v3 api we need to pass a new request parameter to the api. Horizon depends on this for domain support. The call looks like this GET /v3/role_assignments?scope.domain.id=id&include_subtree and the results will return all the project role_assignments for the domain id. This can be further filters by project id in the client code. This is related to https://bugs.launchpad.net/keystone/+bug/1437407 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1462694/+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 1526577] [NEW] Wrong Allocation Pools will disable the 'Next' button
Public bug reported: When create a new network, if user give a wrong Allocation Pools by typo, then user will get an error. And the 'Create' button turned to be 'Next' button and in disabled mode. However, at that moment, even user fix the wrong pools, user will still have to go back instead of let the user try again at current page. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1526577 Title: Wrong Allocation Pools will disable the 'Next' button Status in OpenStack Dashboard (Horizon): New Bug description: When create a new network, if user give a wrong Allocation Pools by typo, then user will get an error. And the 'Create' button turned to be 'Next' button and in disabled mode. However, at that moment, even user fix the wrong pools, user will still have to go back instead of let the user try again at current page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1526577/+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 1523968] Re: LBaaS v2 - LB update with admin-state-down fails
This is not a neutron issue, but a neutronclient side fix, as admin- state-down is not required during Update in any CLI ** Project changed: neutron => python-neutronclient -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1523968 Title: LBaaS v2 - LB update with admin-state-down fails Status in python-neutronclient: New Bug description: Updating loadbalancer instance with admin-state-down fails CLI Command: neutron lbaas-loadbalancer-update --admin-state-down NFV_LB Output: Unrecognized attribute(s) 'admin_state_down' To manage notifications about this bug go to: https://bugs.launchpad.net/python-neutronclient/+bug/1523968/+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 1518087] Re: [RFE] Method to guarantee that at least one mechanism driver implements security groups
Based on discussion [1], we ruled out against of this. Can be revised if justification for rejection is disputed based on other grounds. [1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-08-15.03.log.html ** Changed in: neutron Status: Triaged => 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/1518087 Title: [RFE] Method to guarantee that at least one mechanism driver implements security groups Status in neutron: Won't Fix Bug description: Now we can't get info that MD support SGs or not, and no way to guarantee that at least one MD will be responsible to handle the security group event. And probably other extension like QOS, have the similar problem. more info could be find here https://review.openstack.org/#/c/240356/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1518087/+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 1500365] Re: neutron port API does not support atomicity
Based on discussion [1], if this becomes a burning issue for some other more realistic use case, we can consider introducing an atomic update of the device id and/or device owner field. [1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-15-15.01.log.html ** Changed in: neutron Status: Triaged => 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/1500365 Title: neutron port API does not support atomicity Status in neutron: Won't Fix Bug description: Neutron port API offers an update method where the user of the API can say "I use this port" by setting the device_owner and device_id fields of the port. However the neutron API does not prevent port allocation race conditions. The API semantic is that a port is used if the device_id and the device_owner fields are set, and not used if they aren't. Now lets have two clients that both want to set the ownership of the port. Both clients first have to check if the port is free or not by checking the value of the device_owner and device_id fields of the port, then they have to set the those fields to express ownership. If the two clients act parallel it is pretty much possible that both clients see that the fields are empty and both issue the port update command. This can leads to race conditions between clients. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1500365/+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 1405077] Re: Provide API to manage segmentation ranges
Discussion [1] was not really conclusive, but we should look into providing/refining a mechanism to reload config options via oslo.service primitives and without API interruption. As commented before, we already have some integration in place and more can be done, but it can be done in the context of as separate individual bug fixes. As for what we currently have captured in config options, I'd say let's draw a line in the sand and assume that from here on out we consider more carefully whether certain options are really meant to be statically or manually configured, taking into consideration how often these configs may change throughout the life cycle of the system, and whether they apply across the entire set of plugins that integrate with Neutron. For this reason, I think it's fair to say that this proposal should be marked as "won't fix", because a) vlan range is a plugin/deployment specific config option, and b) with small fixes, it can be reloaded without API interruption, that can be supported via sys management tools. [1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-15-15.01.log.html ** Changed in: neutron Status: Triaged => 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/1405077 Title: Provide API to manage segmentation ranges Status in neutron: Won't Fix Bug description: This bug was reported like this: I changed network_vlan_ranges configuration in configuration file, and I want changes to take effect without restarting the neutron server. It may not be a bug, but restarting the networking service itself could lead to some critical processes to stop temporarily. As some configurations are subjected to change often, automatic reloading of configurations without restarting the whole service may be a feasible solution. However, I think what this is asking for is this: As an administrator I would like to edit my segmentation range via an API (for vlan that would be network_vlan_ranges, vni_ranges for geneve/vxlan, and tunnel_id_ranges for gre), instead of editing the file in place. It would be beneficial for the admin, because if I run out of my range whilst my deployment is up and running I don't want to cause an operational downtime to expand it. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1405077/+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 1495440] Re: bulk delete improvements
Based on discussion [1], let's go with option [1]. Let's limit this to core resources only in the context of this effort. [1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-15-15.01.log.html ** Changed in: neutron Status: Triaged => Won't Fix ** Tags removed: rfe ** Tags added: rfe-approved ** Tags removed: api ** Changed in: neutron Assignee: Reedip (reedip-banerjee) => (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1495440 Title: bulk delete improvements Status in neutron: Won't Fix Status in python-neutronclient: Triaged Bug description: While trying to delete multiple firewall rule using CLI by passing firewall rule multiple times, it deletes only the first firewall Rule id stack@hdp-001:~$ neutron (neutron) firewall-rule-list +--+-++-+-+ | id | name| firewall_policy_id | summary | enabled | +--+-++-+-+ | 8c4ea5c6-a6e4-43ab-a503-0a2265119238 | test1491637 | | TCP,| True| | | | | source: none(none),| | | | | | dest: none(none), | | | | | | allow | | | b8c1c061-8f92-482d-94d3-678f42c7ccd7 | rayrafw2| | ICMP, | True| | | | | source: none(none),| | | | | | dest: none(none), | | | | | | allow | | | ba35dde7-8b07-4ba1-8338-496962c83dbc | testrule1491637 | | UDP,| True| | | | | source: 10.25.10.2/32(80), | | | | | | dest: none(none), | | | | | | deny | | +--+-++-+-+ (neutron) firewall-rule-delete 8c4ea5c6-a6e4-43ab-a503-0a2265119238 b8c1c061-8f92-482d-94d3-678f42c7ccd7 Deleted firewall_rule: 8c4ea5c6-a6e4-43ab-a503-0a2265119238 (neutron) firewall-rule-list +--+-++-+-+ | id | name| firewall_policy_id | summary | enabled | +--+-++-+-+ | b8c1c061-8f92-482d-94d3-678f42c7ccd7 | rayrafw2| | ICMP, | True| | | | | source: none(none),| | | | | | dest: none(none), | | | | | | allow | | | ba35dde7-8b07-4ba1-8338-496962c83dbc | testrule1491637 | | UDP,| True| | | | | source: 10.25.10.2/32(80), | | | | | | dest: none(none), | | | | | | deny | | +--+-++-+-+ (neutron) It will be better if we can delete multiple firewall rule by passing multiple firewall rule id To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1495440/+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.launchp
[Yahoo-eng-team] [Bug 1523716] Re: oslo.utils upgrade breaks unit tests
Neutron no longer affected after oslo.utils 3.2.0 released ** Changed in: neutron Status: New => 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/1523716 Title: oslo.utils upgrade breaks unit tests Status in Ceilometer: Invalid Status in Magnum: New Status in networking-odl: New Status in neutron: Invalid Status in oslo.utils: Fix Released Bug description: Upgraded oslo.utils (3.1.0) is breaking ceilometer unit tests: https://jenkins07.openstack.org/job/gate-ceilometer- python34/897/console Stack Trace: 2015-12-07 20:17:19.296 | __import__(module_str) 2015-12-07 20:17:19.296 | File "ceilometer/notification.py", line 24, in 2015-12-07 20:17:19.296 | from ceilometer import coordination 2015-12-07 20:17:19.296 | File "ceilometer/coordination.py", line 20, in 2015-12-07 20:17:19.297 | import tooz.coordination 2015-12-07 20:17:19.297 | File "/home/jenkins/workspace/gate-ceilometer-python27/.tox/py27/local/lib/python2.7/site-packages/tooz/coordination.py", line 21, in 2015-12-07 20:17:19.297 | from oslo_utils import netutils 2015-12-07 20:17:19.297 | File "/home/jenkins/workspace/gate-ceilometer-python27/.tox/py27/local/lib/python2.7/site-packages/oslo_utils/netutils.py", line 25, in 2015-12-07 20:17:19.297 | import netifaces 2015-12-07 20:17:19.297 | ImportError: No module named netifaces To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1523716/+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 1522732] Re: Add availability_zone support for router
** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: neutron Status: New => 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/1522732 Title: Add availability_zone support for router Status in neutron: Fix Released Status in openstack-manuals: New Bug description: https://review.openstack.org/224418 \Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit ef2a5543cc7e15769031f81c921d4babb7e14d04 Author: Hirofumi Ichihara Date: Thu Dec 3 14:12:19 2015 +0900 Add availability_zone support for router This patch adds the availability_zone support for router. APIImpact DocImpact: Make router scheduler availability zone aware. If multiple availability zones are used, set router_scheduler_driver = neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler. This scheduler selects agent depends on LeastRoutersScheduler logic within an availability zone so that considers the weight of agent. Change-Id: Id26d9494b9a5b459767e93a850f47a3b014b11bb Co-Authored-By: IWAMOTO Toshihiro Partially-implements: blueprint add-availability-zone To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1522732/+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 1457986] Re: RFE: Need API to provide network IP allocation counts
Reviewed: https://review.openstack.org/180803 Committed: https://git.openstack.org/cgit/openstack/neutron-specs/commit/?id=8a8a48216da5fe9c92cf6071a964964f9ef89fbd Submitter: Jenkins Branch:master commit 8a8a48216da5fe9c92cf6071a964964f9ef89fbd Author: dbingham Date: Mon Nov 30 18:54:14 2015 -0700 Network IP Availability Extension API Add a new network IP availability API Extension for operators to predict and react when networks are reaching IP capacity. ip availability api extension rfe APIImpact DocImpact Change-Id: Ifd42982aea5bbfc095e30bd2a221ec472d55519a Implements: blueprint network-ip-usage-api Closes-Bug: 1457986 ** Changed in: neutron Status: In Progress => 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/1457986 Title: RFE: Need API to provide network IP allocation counts Status in neutron: Fix Released Bug description: Operators have requested an API that allows them to quickly and easily determine the IP capacity of a network or subnet. Rather than discovering a network is full, an api could be proactively called by an operator or monitor to give some measure of when a network is reaching its capacity. Some things desired from a new API for both network and subnets * used IPs - How many IPs are reserved from a network/subnet * total IPs - The capacity of IPs for this network/subnet * Enough information about the network/subnet to be able to fetch detailed information about the resource (possible examples: id, name) Naturally used_ips/total_ips gives the user a way to determine the percentage the resource has been consumed. Some references to those needing this API: * Philidelphia operators at the OPs meetup expressed great interest after watching a presentation describing this use. * GoDaddy in-house implementation: In use for 1+ years. Also called by in-house NetworkAwareFilterScheduler. GoDaddy implementation:https://github.com/godaddy/openstack-neutron/commit/fcf325f9f9f7a9f87ba6bc1c53f9212d0e2decee * Rackspace implementation: https://github.com/rackerlabs/quark/blob/master/quark/ip_availability.py#L48 Some notes about related patches (added 2015-11-17): * https://review.openstack.org/180803 (Neutron Spec) * https://review.openstack.org/#/c/212955 (Neutron patch) * https://review.openstack.org/#/c/234541 (Second Neutron patch) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1457986/+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 1518643] Re: Nuage vendor code still present in neutron tree
Reviewed: https://review.openstack.org/255459 Committed: https://git.openstack.org/cgit/openstack/python-neutronclient/commit/?id=a0e20366cf30596a519ce49f2837b3dd575ee8d5 Submitter: Jenkins Branch:master commit a0e20366cf30596a519ce49f2837b3dd575ee8d5 Author: Manjeet Singh Bhatia Date: Wed Dec 9 19:51:23 2015 + Remove nuage plugin from client This remove the nuage code from client Change-Id: I7a3bdbedc429015258e76506da950226cacb07e8 Closes-Bug: #1518643 ** Changed in: python-neutronclient Status: In Progress => 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/1518643 Title: Nuage vendor code still present in neutron tree Status in neutron: Fix Released Status in python-neutronclient: Fix Released Bug description: The Nuage plugins and ML2 mechanism drivers should be completely removed from the neutron tree. See http://docs.openstack.org/developer/neutron/devref/contribute.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1518643/+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 1175686] Re: Documentation doesn't explain how to install virtualenv
Fix proposed to branch: master Review: https://review.openstack.org/258188 ** Changed in: keystone Status: Opinion => In Progress ** Changed in: keystone Assignee: Raildo Mascena de Sousa Filho (raildo) => John Dewey (retr0h) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1175686 Title: Documentation doesn't explain how to install virtualenv Status in OpenStack Identity (keystone): In Progress Bug description: In the page "Setting up a Keystone development environment" (http://docs.openstack.org/developer/keystone/setup.html), the section "Installing dependencies", the subsection "PyPi Packages and VirtualEnv" recommends to set up a virtual environment. However, it doesn't explain how to set it up: edu@petra:~/OpenStack/keystone$ python tools/install_venv.py ERROR: virtualenv not found. Keystone development requires virtualenv, please install it using your favorite package management tool The following package is required: sudo apt-get install python-virtualenv To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175686/+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 1504465] Re: neutron_lbaas.tests.tempest.v2.api.test_health_monitors_non_admin.TestHealthMonitors failed to clean up loadbalancer
Reviewed: https://review.openstack.org/255017 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f218929bc5126466b2a79b56d32e9cf042aa176d Submitter: Jenkins Branch:master commit f218929bc5126466b2a79b56d32e9cf042aa176d Author: Brandon Logan Date: Tue Dec 8 18:24:28 2015 -0600 Force service provider relationships to load A race condition was exposed in the LBaaS V2 db layer that was caused by a hack to get around this issue. The real issue is that since the ProviderResourceAssociation is inserted independently, any models that were created before this insert will not have their relationship with the ProviderResourceAssocation loaded. Using the session.expire_all method will force the session to retrieve all new data and load this relationship for any resource that uses this relationship. Change-Id: I940b541f4ef9c489126cd2d215b1d857f0624de0 Closes-Bug: #1504465 ** Changed in: neutron Status: In Progress => 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/1504465 Title: neutron_lbaas.tests.tempest.v2.api.test_health_monitors_non_admin.TestHealthMonitors failed to clean up loadbalancer Status in neutron: Fix Released Bug description: http://logs.openstack.org/15/229915/3/gate/gate-neutron-lbaasv2-dsvm- minimal/5dc60be/logs/testr_results.html.gz ft1.2: tearDownClass (neutron_lbaas.tests.tempest.v2.api.test_health_monitors_non_admin.TestHealthMonitors)_StringException: Traceback (most recent call last): File "neutron_lbaas/tests/tempest/lib/test.py", line 310, in tearDownClass six.reraise(etype, value, trace) File "neutron_lbaas/tests/tempest/lib/test.py", line 293, in tearDownClass teardown() File "neutron_lbaas/tests/tempest/v2/api/base.py", line 96, in resource_cleanup cls._try_delete_resource(cls._delete_load_balancer, lb_id) File "neutron_lbaas/tests/tempest/v1/api/base.py", line 185, in _try_delete_resource delete_callable(*args, **kwargs) File "neutron_lbaas/tests/tempest/v2/api/base.py", line 137, in _delete_load_balancer load_balancer_id, delete=True) File "neutron_lbaas/tests/tempest/v2/api/base.py", line 160, in _wait_for_load_balancer_status load_balancer_id) File "neutron_lbaas/tests/tempest/v2/clients/load_balancers_client.py", line 42, in get_load_balancer resp, body = self.get(url) File "/usr/local/lib/python2.7/dist-packages/tempest_lib/common/rest_client.py", line 274, in get return self.request('GET', url, extra_headers, headers) File "/usr/local/lib/python2.7/dist-packages/tempest_lib/common/rest_client.py", line 646, in request resp, resp_body) File "/usr/local/lib/python2.7/dist-packages/tempest_lib/common/rest_client.py", line 760, in _error_checker message=message) tempest_lib.exceptions.ServerFault: Got server fault Details: Request Failed: internal server error while processing your request. Server failure is: 2015-10-08 23:22:56.409 ERROR neutron.api.v2.resource [req-fafd7f88-2e1a-41ce-85c1-9dbacc6f1d93 TestHealthMonitors-867400801 TestHealthMonitors-1196952833] show failed 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource Traceback (most recent call last): 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/resource.py", line 83, in resource 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource result = method(request=request, **args) 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/base.py", line 359, in show 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource parent_id=parent_id), 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/base.py", line 311, in _item 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource obj = obj_getter(request.context, id, **kwargs) 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron-lbaas/neutron_lbaas/services/loadbalancer/plugin.py", line 560, in get_loadbalancer 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource return self.db.get_loadbalancer(context, id).to_api_dict() 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron-lbaas/neutron_lbaas/db/loadbalancer/loadbalancer_dbv2.py", line 268, in get_loadbalancer 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource lb_db = self._get_resource(context, models.LoadBalancer, id) 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron-lbaas/neutron_lbaas/db/loadbalancer/loadbalancer_dbv2.py", line 73, in _get_resource 2015-10-08 23:22:56.409 13383 ERROR neutron.api.v2.resource
[Yahoo-eng-team] [Bug 1526559] [NEW] L3 agent parallel configuration of routers might slow things down
Public bug reported: In the L3 agent's _process_routers_loop method, it spawns a GreenPool with 8 eventlet threads. Those threads then take updates off the agent's queue and process router updates. Router updates are serialized by router_id so that two threads don't process the same router at any given time. In an environment running on a powerful baremetal server, on agent restart it was trying to sync roughly 600 routers. Around half were HA routers, and half were legacy routers. With the default GreenPool size of 8, the result was that the server ground to a halt as CPU usage skyrocketed to over 600%. The main offenders were ip, bash, keepalived and Python. This was on an environment without rootwrap daemon based off stable/juno. It took around 60 seconds to configure a single router. Changing the GreenPool size from 8 to 1, caused the agent to: 1) Configure a router in 30 seconds, a 50% improvement. 2) Reduce CPU load from 600% to 70%, freeing the machine to do other things. I'm filing this bug so that: 1) Someone can confirm my personal experience in a more controlled way - For example, graph router configuration time and CPU load as a result of GreenPool size. 2) If my findings are confirmed on master with rootwrap daemon, start considering alternatives like multiprocessing instead of eventlet multithreading, or at the very least optimize the GreenPool size. ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-ipam-dhcp loadimpact -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1526559 Title: L3 agent parallel configuration of routers might slow things down Status in neutron: New Bug description: In the L3 agent's _process_routers_loop method, it spawns a GreenPool with 8 eventlet threads. Those threads then take updates off the agent's queue and process router updates. Router updates are serialized by router_id so that two threads don't process the same router at any given time. In an environment running on a powerful baremetal server, on agent restart it was trying to sync roughly 600 routers. Around half were HA routers, and half were legacy routers. With the default GreenPool size of 8, the result was that the server ground to a halt as CPU usage skyrocketed to over 600%. The main offenders were ip, bash, keepalived and Python. This was on an environment without rootwrap daemon based off stable/juno. It took around 60 seconds to configure a single router. Changing the GreenPool size from 8 to 1, caused the agent to: 1) Configure a router in 30 seconds, a 50% improvement. 2) Reduce CPU load from 600% to 70%, freeing the machine to do other things. I'm filing this bug so that: 1) Someone can confirm my personal experience in a more controlled way - For example, graph router configuration time and CPU load as a result of GreenPool size. 2) If my findings are confirmed on master with rootwrap daemon, start considering alternatives like multiprocessing instead of eventlet multithreading, or at the very least optimize the GreenPool size. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1526559/+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 1516031] Re: Use of MD5 in OpenStack Glance image signature (CVE-2015-8234)
This issue has been published as OSSN-0061: https://wiki.openstack.org/wiki/OSSN/OSSN-0061 ** Changed in: ossn Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1516031 Title: Use of MD5 in OpenStack Glance image signature (CVE-2015-8234) Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: This have been reported by Daniel P. Berrange: " In the OpenStack Liberty release, the Glance project added support for image signature verification. http://specs.openstack.org/openstack/glance-specs/specs/liberty/image- signing-and-verification-support.html The verification code was added in the following git commit https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb4b04ff6e Unfortunately the design of this signature verification method is flawed by design. The generalized approach to creating signatures of content is to apply a hash to the content and then encrypt it in some manner. Consider that the signature is defined to use hash=sha256 and cipher=rsa we can describe the signature computation as signature = rsa(sha256(content)) In the case of verifying a disk image, the content we care about verifying is the complete disk image file. Unfortunately, the glance specification chose *not* to compute the signature against the disk image file. Glance already had an MD5 checksum calculated for the disk image file, so they instead chose to compute the signature against the MD5 checksum instead. ie glance is running signature = rsa(sha256(md5(disk-image-content))) This degrades the security of the system to that of the weakest hash, which is obviously MD5 here. The code where glance verifies the signature is in the glance/locations.py, the 'set_data' method where is does result = signature_utils.verify_signature( self.context, checksum, self.image.extra_properties) if result: LOG.info(_LI("Successfully verified signature for image %s"), self.image.image_id) The 'checksum' variable is populate by the glance_store driver, but it is hardcoded to always be md5 in all current glance storage backends: $ git grep hashlib glance_store/_drivers/ | grep checksum glance_store/_drivers/filesystem.py: checksum = hashlib.md5() glance_store/_drivers/rbd.py: checksum = hashlib.md5() glance_store/_drivers/s3.py: checksum = hashlib.md5() glance_store/_drivers/s3.py: checksum = hashlib.md5() glance_store/_drivers/sheepdog.py: checksum = hashlib.md5() glance_store/_drivers/swift/store.py: checksum = hashlib.md5() glance_store/_drivers/vmware_datastore.py: self.checksum = hashlib.md5() Since we will soon be shipping OpenStack Liberty release, we need to at least give a security notice to alert our customers to the fact that the signature verification is cryptographically weak/broken. IMHO, it quite likely deserves a CVE though NB, this is public knowledge as I first became aware of this flawed design in comments / discussion on a public specification proposed to implement the same approach in the Nova project. My suggested way to fix this is to simply abandon the current impl and re-do it such that it directly computes the signature against the disk image, and does not use the existing md5 checksum in any way. Regards, Daniel " Mailing list thread for Nova impl: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079348.html Nova Spec: https://review.openstack.org/#/c/188874/ To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1516031/+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 1508869] Re: DVR: handle dvr serviceable port's host change
Reviewed: https://review.openstack.org/238478 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=189a6f1bc3295b719304f44e5b731ef671fe7f50 Submitter: Jenkins Branch:master commit 189a6f1bc3295b719304f44e5b731ef671fe7f50 Author: Oleg Bondarev Date: Thu Oct 22 13:23:21 2015 +0300 DVR: handle dvr serviceable port's host change When a VM port's host is changed we need to check if a router should be unscheduled from old host and send corresponding notifications. commit d5a8074ec3c67ed68e64a96827da990f1c34e10f added such a check when port is unbound. This patch adds similar check in case of host change (instance live migration) Closes-Bug: #1508869 Change-Id: I57fa8253b2c88f7b7380a79b841fc424e9e52f19 ** Changed in: neutron Status: In Progress => 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/1508869 Title: DVR: handle dvr serviceable port's host change Status in neutron: Fix Released Bug description: When a VM port's host is changed we need to check if router should be unscheduled from old host and send corresponding notifications. commit d5a8074ec3c67ed68e64a96827da990f1c34e10f added such a check when port is unbound. Need to add similar check in case of host change. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1508869/+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 1490804] Re: PKI Token Revocation Bypass (CVE-2015-7546)
** Changed in: keystone Status: Won't Fix => In Progress ** Changed in: keystone Assignee: Adam Young (ayoung) => Brant Knudson (blk-u) ** Changed in: keystonemiddleware Status: Won't Fix => In Progress ** Changed in: keystonemiddleware Assignee: Adam Young (ayoung) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1490804 Title: PKI Token Revocation Bypass (CVE-2015-7546) Status in django-openstack-auth: Invalid Status in OpenStack Identity (keystone): In Progress Status in keystonemiddleware: In Progress Status in OpenStack Security Advisory: Incomplete Status in OpenStack Security Notes: New Status in python-keystoneclient: Won't Fix Bug description: A keystone token which has been revoked can still be used by manipulating particular byte fields within the token. When a Keystone token is revoked it is added to the revoked list which stores the exact token value. Any API will look at the token to see whether or not it should accept a token. By changing a single byte within the token, the revocation can be bypassed. see the testing script [1]. It is suggested that the revocation should be changed to only check the token's inner ID. [1] http://paste.openstack.org/show/436516/ To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1490804/+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 1525295] Re: subnet listing is too slow with rbac
Reviewed: https://review.openstack.org/256609 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f5b950dffecc049df11981dcfb5574121be3eb69 Submitter: Jenkins Branch:master commit f5b950dffecc049df11981dcfb5574121be3eb69 Author: Kevin Benton Date: Fri Dec 11 09:56:01 2015 -0800 Separate rbac calculation from _make_network_dict When a subnet dict was being created, it was calling _make_network_dict to get the 'shared' flag for the subnet. The issue with this is that the _make_network_dict function would iterate over the subnets on the passed in network object, which would trigger a database lookup of all of the subnets. This patch just separates the 'shared' flag calculation out into a separate function that both calls can leverage. Change-Id: I2cb766ce1fd8ddcc75209f9e92221a3b77015ea2 Closes-Bug: #1525295 Partial-Bug: #1513782 ** Changed in: neutron Status: In Progress => 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/1525295 Title: subnet listing is too slow with rbac Status in neutron: Fix Released Bug description: subnet listing of 100 subnets takes about 2 seconds on a powerfull hardware. 60% of the time is consumed by the calculation of 'shared' attribute of the subnet which involves rbac rules. This makes horizon barely usable as number of networks grow. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525295/+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 1524562] Re: No error raised if PUT/GET/PATCH/DELETE domain-specific driver configuration database store with an invalid domain id
Reviewed: https://review.openstack.org/256889 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=5560c7060dcc906b07080c44511551c45172ecf0 Submitter: Jenkins Branch:master commit 5560c7060dcc906b07080c44511551c45172ecf0 Author: Thomas Hsiao Date: Fri Dec 11 15:55:19 2015 -0800 Validate domain for DB-based domain config. CRUD For CRUD of Identity API-based domain-specific driver configuration in database store, if the client provides an invalid domain id, the request shall be rejected with a response 404 domain not found. Change-Id: I9e861d450da1a49d31bac08bea12a0e2e84c6476 Closes-Bug: 1524562 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1524562 Title: No error raised if PUT/GET/PATCH/DELETE domain-specific driver configuration database store with an invalid domain id Status in OpenStack Identity (keystone): Fix Released Bug description: No error raised if PUT/GET/PATCH/DELETE sql-based domain driver configuration with a invalid domain id: For domain-specific driver configuration database store, Identity API creates the configuration options into the database even though the provided domain id is the the request url is invalid. For example, a user can create config options using an invalid domain id (123456789) as shown below: ~$ curl -s \ > -H "X-Auth-Token: ADMIN" \ > -H "Content-Type: application/json" \ > -d ' > { >"config":{ > "identity":{ > "driver":"ldap" > }, > "ldap":{ > . > "tls_req_cert":"demand", > "user_tree_dn":"ou=Users50,dc=cdl,dc=hp,dc=com", > "group_allow_update":"False" > } >} > } ' \ > -XPUT "http://localhost:35357/v3/domains/123456789/config/"; {"config": {"identity": {"driver": "keystone.identity.backends.ldap.Identity"}, "ldap": {"user_allow_update": "False", "user_name_attribute": "cn", "use_pool": "True", "user_objectclass": "posixAccount", "group_id_attribute": "gidNumber", "user_allow_create": "False", "tls_req_cert": "demand"...}}} Once the config options created in the database, the user can even use this invalid domain id to get/update/delete the config options, an example as shown below: ~$ curl -k -H "X-Auth-Token:ADMIN" http://localhost:35357/v3/domains/123456789/config/ {"config": {"identity": {"driver": "keystone.identity.backends.ldap.Identity"}, "ldap": {"user_allow_update": "False", "group_allow_delete": "False", "group_name_attribute": "cn", "suffix": "dc=cdl,dc=hp,dc=com", .., "group_allow_update": "False"...}}} To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1524562/+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 1353939] Re: Rescue fails with 'Failed to terminate process: Device or resource busy' in the n-cpu log
This fix was made available in 1:2014.2.4-0ubuntu1~cloud4 of nova in the Ubuntu Cloud Archive for Juno. ** Changed in: cloud-archive/juno Status: In Progress => Fix Committed ** Changed in: cloud-archive/juno Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1353939 Title: Rescue fails with 'Failed to terminate process: Device or resource busy' in the n-cpu log Status in Ubuntu Cloud Archive: Invalid Status in Ubuntu Cloud Archive juno series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: New Status in OpenStack Compute (nova) kilo series: Fix Released Status in nova package in Ubuntu: Invalid Bug description: [Impact] * Users may sometimes fail to shutdown an instance if the associated qemu process is on uninterruptable sleep (typically IO). [Test Case] * 1. create some IO load in a VM 2. look at the associated qemu, make sure it has STAT D in ps output 3. shutdown the instance 4. with the patch in place, nova will retry calling libvirt to shutdown the instance 3 times to wait for the signal to be delivered to the qemu process. [Regression Potential] * None message: "Failed to terminate process" AND message:'InstanceNotRescuable' AND message: 'Exception during message handling' AND tags:"screen-n-cpu.txt" The above log stash-query reports back only the failed jobs, the 'Failed to terminate process' close other failed rescue tests, but tempest does not always reports them as an error at the end. message: "Failed to terminate process" AND tags:"screen-n-cpu.txt" Usual console log: Details: (ServerRescueTestJSON:test_rescue_unrescue_instance) Server 0573094d-53da-40a5-948a-747d181462f5 failed to reach RESCUE status and task state "None" within the required time (196 s). Current status: SHUTOFF. Current task state: None. http://logs.openstack.org/82/107982/2/gate/gate-tempest-dsvm-postgres- full/90726cb/console.html#_2014-08-07_03_50_26_520 Usual n-cpu exception: http://logs.openstack.org/82/107982/2/gate/gate-tempest-dsvm-postgres-full/90726cb/logs/screen-n-cpu.txt.gz#_2014-08-07_03_32_02_855 2014-08-07 03:32:02.855 ERROR oslo.messaging.rpc.dispatcher [req-39ce7a3d-5ceb-41f5-8f9f-face7e608bd1 ServerRescueTestJSON-2035684545 ServerRescueTestJSON-1017508309] Exception during message handling: Instance 0573094d-53da-40a5-948a-747d181462f5 cannot be rescued: Driver Error: Failed to terminate process 26425 with SIGKILL: Device or resource busy 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher Traceback (most recent call last): 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 134, in _dispatch_and_reply 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher incoming.message)) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 177, in _dispatch 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return self._do_dispatch(endpoint, method, ctxt, args) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 123, in _do_dispatch 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher result = getattr(endpoint, method)(ctxt, **new_args) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/compute/manager.py", line 408, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/exception.py", line 88, in wrapped 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher payload) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/openstack/common/excutils.py", line 82, in __exit__ 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/exception.py", line 71, in wrapped 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return f(self, context, *args, **kw) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File "/opt/stack/new/nova/nova/compute/manager.py", line 292, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher pass 2014-08-07 03:32:02.855
[Yahoo-eng-team] [Bug 1526436] [NEW] {RFE] Add support for VMware Edge appliance loadbalancer to neutron lbaas
Public bug reported: VMware NSX networking virtualization offers various networking functions with the build-in Edge appliances. One of the features which the Edge appliance has is a built-in load balancer. This load balancer is currently supported by an LBaaS v1 driver, but has no LBaaS v2 support. Support for v2 is required before v1 deprecation. ** Affects: neutron Importance: Undecided Assignee: Kobi Samoray (ksamoray) Status: In Progress ** Tags: lbaas rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1526436 Title: {RFE] Add support for VMware Edge appliance loadbalancer to neutron lbaas Status in neutron: In Progress Bug description: VMware NSX networking virtualization offers various networking functions with the build-in Edge appliances. One of the features which the Edge appliance has is a built-in load balancer. This load balancer is currently supported by an LBaaS v1 driver, but has no LBaaS v2 support. Support for v2 is required before v1 deprecation. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1526436/+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 1522524] Re: User can delete deactivated images
Until a clear consensus about whenever this bug caused an actual security vulnerability, the OSSA task is now Won't Fix. ** Changed in: ossa Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1522524 Title: User can delete deactivated images Status in Glance: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: Overview: In glance once an admin has marked a image as deactivated a user can no longer download or delete that image. This is so an image can be inspected by the admins without the user interfering. However, these restrictions can be avoided specifically allowing a user to delete a deactivated image. Meaning an admin would not be able to guarantee the status of a deactivated image. What should happen: 403 What does happen: 200 How to reproduce: 1. Create an image. echo test | glance image-create --name 3 --container-format bare --disk-format raw 2. Deactivate the image. glance image-deactivate 0630d5e4-6009-4723-94e6-1ad056ab649a 3. Check image is deactivated. glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a 4. Using the v1 API delete the image. curl -X DELETE http://localhost:9292/v1/images/0630d5e4-6009-4723-94e6-1ad056ab649a -H 'X-Auth-token: 108322e43f6346ebadb3c2fb72831913' 5. Image is now gone. glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1522524/+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 1525279] Re: Request Liberty release for networking-bgpvpn
This is now published to PyPI: https://pypi.python.org/pypi/networking- bgpvpn/3.0.0 ** Changed in: neutron Status: In Progress => Fix Released ** Changed in: neutron Milestone: None => mitaka-2 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1525279 Title: Request Liberty release for networking-bgpvpn Status in bgpvpn: New Status in neutron: Fix Released Bug description: The networking-bgpvpn project is now ready to have its first release. We'd like to create a dedicated branch to backport needed patches in the future. Release Info : Current branch : master Commit-Id : 157f73d3f248f1e1008e1e7f908dd616762325bc New Tag: 3.0.0 To manage notifications about this bug go to: https://bugs.launchpad.net/bgpvpn/+bug/1525279/+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 1526137] [NEW] when upgrade openstack-dashboard many times, httpd service start failed
You have been subscribed to a public bug: there is a bug in post script of openstack-horizon.spec : %post -n openstack-dashboard # ugly hack to set a unique SECRET_KEY sed -i "/^from horizon.utils import secret_key$/d" /etc/openstack-dashboard/local_settings sed -i "/^SECRET_KEY.*$/{N;s/^.*$/SECRET_KEY='`openssl rand -hex 10`'/}" /etc/openstack-dashboard/local_settings When upgrading dashboard rpm, SECRET_KEY in /etc/openstack- dashboard/local_settings will be updated, and it will be swallow a line of the config file at the same time. so after upgrding openstack- dashboard for twelve times, the line of "CACHES = {" will be deleted, and the bug happened. ** Affects: horizon Importance: Undecided Status: New -- when upgrade openstack-dashboard many times, httpd service start failed https://bugs.launchpad.net/bugs/1526137 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). -- 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 1526137] Re: when upgrade openstack-dashboard many times, httpd service start failed
** Project changed: openstack-community => horizon -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1526137 Title: when upgrade openstack-dashboard many times, httpd service start failed Status in OpenStack Dashboard (Horizon): New Bug description: there is a bug in post script of openstack-horizon.spec : %post -n openstack-dashboard # ugly hack to set a unique SECRET_KEY sed -i "/^from horizon.utils import secret_key$/d" /etc/openstack-dashboard/local_settings sed -i "/^SECRET_KEY.*$/{N;s/^.*$/SECRET_KEY='`openssl rand -hex 10`'/}" /etc/openstack-dashboard/local_settings When upgrading dashboard rpm, SECRET_KEY in /etc/openstack- dashboard/local_settings will be updated, and it will be swallow a line of the config file at the same time. so after upgrding openstack-dashboard for twelve times, the line of "CACHES = {" will be deleted, and the bug happened. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1526137/+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 1525464] Re: Release request of networking-cisco and creation of stable/liberty 2.0.0
This is on PyPI now: https://pypi.python.org/pypi/networking-cisco/2.0.0 ** Changed in: neutron Status: In Progress => Fix Released ** Changed in: neutron Milestone: None => mitaka-2 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1525464 Title: Release request of networking-cisco and creation of stable/liberty 2.0.0 Status in networking-cisco: New Status in neutron: Fix Released Bug description: networking-cisco has NOT yet been branched for stable/liberty this needs to be done alone with tagging the first release at 2.0.0 Branch and tag at hash: cccaa1d12b81e17756dbef216048d76d008df54d To manage notifications about this bug go to: https://bugs.launchpad.net/networking-cisco/+bug/1525464/+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 1526413] Re: test_app_using_ipv6_and_ssl fails with requests 2.9.0
Reviewed: https://review.openstack.org/258001 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ba82e4a875f01bb883deb78517953989b690a36c Submitter: Jenkins Branch:master commit ba82e4a875f01bb883deb78517953989b690a36c Author: Matt Riedemann Date: Tue Dec 15 08:38:17 2015 -0800 Block requests 2.9.0 Breaks the wsgi IPv6 unit tests. Depends-On: Ifb080c72a16ed4b93040fb7c06bdc072b7247f6e Change-Id: I158bd1cba9bc85521ac0e236f66e7780a59e9ac2 Closes-Bug: #1526413 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1526413 Title: test_app_using_ipv6_and_ssl fails with requests 2.9.0 Status in OpenStack Compute (nova): Fix Released Bug description: http://logs.openstack.org/50/257950/1/check/gate-nova- python27/6dfe685/testr_results.html.gz ft1.13019: nova.tests.unit.test_wsgi.TestWSGIServerWithSSL.test_app_using_ipv6_and_ssl_StringException: Empty attachments: stdout pythonlogging:'': {{{ 2015-12-15 15:55:06,381 WARNING [oslo_reports.guru_meditation_report] Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be registered in a future release, so please use SIGUSR2 to generate reports. 2015-12-15 15:55:06,383 INFO [nova.wsgi] fake_ssl listening on ::1:54837 2015-12-15 15:55:06,390 INFO [nova.fake_ssl.wsgi.server] (6121) wsgi starting up on https://::1:54837/ }}} stderr: {{{ /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning. SNIMissingWarning /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning. InsecurePlatformWarning }}} Traceback (most recent call last): File "nova/tests/unit/test_wsgi.py", line 333, in test_app_using_ipv6_and_ssl verify=os.path.join(SSL_CERT_DIR, 'ca.crt')) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py", line 67, in get return request('get', url, params=params, **kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py", line 53, in request return session.request(method=method, url=url, **kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py", line 468, in request resp = self.send(prep, **send_kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py", line 576, in send r = adapter.send(request, **kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/adapters.py", line 447, in send raise SSLError(e, request=request) requests.exceptions.SSLError: hostname '[::1]' doesn't match either of 'localhost', 'ip6-localhost', '127.0.0.1', '::1' http://logstash.openstack.org/#dashboard/file/logstash.json?query=message:%5C%22requests.exceptions.SSLError:%20hostname%20'%5B::1%5D'%20doesn't%20match%20either%20of%20'localhost',%20'ip6-localhost',%20'127.0.0.1',%20'::1'%5C%22%20AND%20tags:%5C%22console%5C%22 just started today when requests 2.9.0 was released: https://pypi.python.org/pypi/requests/2.9.0 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1526413/+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 1526446] Re: compute evacuate documentation doesn't match api behavior
this shouldn't be affecting keystone, just the api-site, and specifically nova APIs ** Changed in: keystone Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1526446 Title: compute evacuate documentation doesn't match api behavior Status in OpenStack Identity (keystone): Invalid Status in openstack-api-site: New Bug description: I am using OpenStack Liberty, installed using the ansible all-in-one deployment. The documentation for the evacuate command in the compute v2.1 API does not appear to match what I am seeing. http://developer.openstack.org/api-ref-compute-v2.1.html#evacuate 1. The on_shared_storage attribute in the documentation should actually be onSharedStorage. When I use on_shared_storage, I get the following error message: "Invalid input for field/attribute evacuate. Value: {u'on_shared_storage': False}. Additional properties are not allowed (u'on_shared_storage' was unexpected)". When I leave the attribute off entirely, I get this error which lead me to the correct attribute name: "Invalid input for field/attribute evacuate. Value: {}. 'onSharedStorage' is a required property". 2. The admin_password attribute in the documentation does not appear to be a valid attribute at all. When I use admin_password, I get the following error message: "Invalid input for field/attribute evacuate. Value: {u'onSharedStorage': False, u'admin_password': u'top-secret- password'}. Additional properties are not allowed (u'admin_password' was unexpected)". I also tried adminPassword (see #1 as for why I thought that may work) but that was rejected with a similar error message. Here is the response from the compute versions endpoint, in case that helps narrow down which version I am using. I am not sending a microversion header. { "versions": [ { "status": "SUPPORTED", "updated": "2011-01-21T11:33:21Z", "links": [ { "href": "http://104.130.30.68:8774/v2/";, "rel": "self" } ], "min_version": "", "version": "", "id": "v2.0" }, { "status": "CURRENT", "updated": "2013-07-23T11:33:21Z", "links": [ { "href": "http://104.130.30.68:8774/v2.1/";, "rel": "self" } ], "min_version": "2.1", "version": "2.12", "id": "v2.1" } ] } To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1526446/+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 1526413] Re: test_app_using_ipv6_and_ssl fails with requests 2.9.0
** Also affects: nova/liberty Importance: Undecided Status: New ** Changed in: nova/liberty Status: New => Confirmed ** Changed in: nova/liberty Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1526413 Title: test_app_using_ipv6_and_ssl fails with requests 2.9.0 Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) liberty series: Confirmed Bug description: http://logs.openstack.org/50/257950/1/check/gate-nova- python27/6dfe685/testr_results.html.gz ft1.13019: nova.tests.unit.test_wsgi.TestWSGIServerWithSSL.test_app_using_ipv6_and_ssl_StringException: Empty attachments: stdout pythonlogging:'': {{{ 2015-12-15 15:55:06,381 WARNING [oslo_reports.guru_meditation_report] Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be registered in a future release, so please use SIGUSR2 to generate reports. 2015-12-15 15:55:06,383 INFO [nova.wsgi] fake_ssl listening on ::1:54837 2015-12-15 15:55:06,390 INFO [nova.fake_ssl.wsgi.server] (6121) wsgi starting up on https://::1:54837/ }}} stderr: {{{ /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning. SNIMissingWarning /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning. InsecurePlatformWarning }}} Traceback (most recent call last): File "nova/tests/unit/test_wsgi.py", line 333, in test_app_using_ipv6_and_ssl verify=os.path.join(SSL_CERT_DIR, 'ca.crt')) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py", line 67, in get return request('get', url, params=params, **kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py", line 53, in request return session.request(method=method, url=url, **kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py", line 468, in request resp = self.send(prep, **send_kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py", line 576, in send r = adapter.send(request, **kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/adapters.py", line 447, in send raise SSLError(e, request=request) requests.exceptions.SSLError: hostname '[::1]' doesn't match either of 'localhost', 'ip6-localhost', '127.0.0.1', '::1' http://logstash.openstack.org/#dashboard/file/logstash.json?query=message:%5C%22requests.exceptions.SSLError:%20hostname%20'%5B::1%5D'%20doesn't%20match%20either%20of%20'localhost',%20'ip6-localhost',%20'127.0.0.1',%20'::1'%5C%22%20AND%20tags:%5C%22console%5C%22 just started today when requests 2.9.0 was released: https://pypi.python.org/pypi/requests/2.9.0 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1526413/+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 1523357] Re: fwaas tempest tests are failing
fixed in fwaas repo ** Changed in: networking-midonet Status: In Progress => Fix Released ** Changed in: networking-midonet Milestone: None => 2.0.0 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1523357 Title: fwaas tempest tests are failing Status in networking-midonet: Fix Released Status in neutron: Fix Released Bug description: recently added fwaas tests are failing in gate-tempest-dsvm-networking-midonet-v2 job. eg. test_firewall_admin_disable http://logs.openstack.org/87/199387/8/check/gate-tempest-dsvm- networking-midonet-v2/3fb3f3b/logs/testr_results.html.gz To manage notifications about this bug go to: https://bugs.launchpad.net/networking-midonet/+bug/1523357/+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 1526446] [NEW] compute evacuate documentation doesn't match api behavior
Public bug reported: I am using OpenStack Liberty, installed using the ansible all-in-one deployment. The documentation for the evacuate command in the compute v2.1 API does not appear to match what I am seeing. http://developer.openstack.org/api-ref-compute-v2.1.html#evacuate 1. The on_shared_storage attribute in the documentation should actually be onSharedStorage. When I use on_shared_storage, I get the following error message: "Invalid input for field/attribute evacuate. Value: {u'on_shared_storage': False}. Additional properties are not allowed (u'on_shared_storage' was unexpected)". When I leave the attribute off entirely, I get this error which lead me to the correct attribute name: "Invalid input for field/attribute evacuate. Value: {}. 'onSharedStorage' is a required property". 2. The admin_password attribute in the documentation does not appear to be a valid attribute at all. When I use admin_password, I get the following error message: "Invalid input for field/attribute evacuate. Value: {u'onSharedStorage': False, u'admin_password': u'top-secret- password'}. Additional properties are not allowed (u'admin_password' was unexpected)". I also tried adminPassword (see #1 as for why I thought that may work) but that was rejected with a similar error message. Here is the response from the compute versions endpoint, in case that helps narrow down which version I am using. I am not sending a microversion header. { "versions": [ { "status": "SUPPORTED", "updated": "2011-01-21T11:33:21Z", "links": [ { "href": "http://104.130.30.68:8774/v2/";, "rel": "self" } ], "min_version": "", "version": "", "id": "v2.0" }, { "status": "CURRENT", "updated": "2013-07-23T11:33:21Z", "links": [ { "href": "http://104.130.30.68:8774/v2.1/";, "rel": "self" } ], "min_version": "2.1", "version": "2.12", "id": "v2.1" } ] } ** Affects: keystone Importance: Undecided Status: New ** Affects: openstack-api-site Importance: Undecided Status: New ** Also affects: openstack-api-site Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1526446 Title: compute evacuate documentation doesn't match api behavior Status in OpenStack Identity (keystone): New Status in openstack-api-site: New Bug description: I am using OpenStack Liberty, installed using the ansible all-in-one deployment. The documentation for the evacuate command in the compute v2.1 API does not appear to match what I am seeing. http://developer.openstack.org/api-ref-compute-v2.1.html#evacuate 1. The on_shared_storage attribute in the documentation should actually be onSharedStorage. When I use on_shared_storage, I get the following error message: "Invalid input for field/attribute evacuate. Value: {u'on_shared_storage': False}. Additional properties are not allowed (u'on_shared_storage' was unexpected)". When I leave the attribute off entirely, I get this error which lead me to the correct attribute name: "Invalid input for field/attribute evacuate. Value: {}. 'onSharedStorage' is a required property". 2. The admin_password attribute in the documentation does not appear to be a valid attribute at all. When I use admin_password, I get the following error message: "Invalid input for field/attribute evacuate. Value: {u'onSharedStorage': False, u'admin_password': u'top-secret- password'}. Additional properties are not allowed (u'admin_password' was unexpected)". I also tried adminPassword (see #1 as for why I thought that may work) but that was rejected with a similar error message. Here is the response from the compute versions endpoint, in case that helps narrow down which version I am using. I am not sending a microversion header. { "versions": [ { "status": "SUPPORTED", "updated": "2011-01-21T11:33:21Z", "links": [ { "href": "http://104.130.30.68:8774/v2/";, "rel": "self" } ], "min_version": "", "version": "", "id": "v2.0" }, { "status": "CURRENT", "updated": "2013-07-23T11:33:21Z", "links": [ { "href": "http://104.130.30.68:8774/v2.1/";, "rel": "self" } ], "min_version": "2.1", "version": "2.12", "id": "v2.1" } ] } To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1526446/+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.lau
[Yahoo-eng-team] [Bug 1526369] [NEW] nova.tests.unit.virt.xenapi.test_vmops.BootableTestCase.test_set_bootable is racy on py34
Public bug reported: http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22mox3.mox.UnexpectedMethodCallError:%20Unexpected%20method%20call%20function.__call__(%3Cnova.virt.xenapi.client.session.XenAPISession%5C%22%20AND%20tags:%5C%22console%5C%22%20AND%20build_name:%5C %22gate-nova-python34%5C%22 ft1.7942: nova.tests.unit.virt.xenapi.test_vmops.BootableTestCase.test_set_bootable_StringException: Empty attachments: stdout pythonlogging:'': {{{2015-12-15 13:33:23,562 WARNING [oslo_reports.guru_meditation_report] Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be registered in a future release, so please use SIGUSR2 to generate reports.}}} stderr: {{{ /home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/pkg_resources/__init__.py:213: RuntimeWarning: You have iterated over the result of pkg_resources.parse_version. This is a legacy behavior which is inconsistent with the new version class introduced in setuptools 8.0. In most cases, conversion to a tuple is unnecessary. For comparison of versions, sort the Version instances directly. If you have another use case requiring the tuple, please file a bug with the setuptools project describing that need. stacklevel=1, }}} Traceback (most recent call last): File "/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/mox3/mox.py", line 1153, in _PopNextMethod return self._call_queue.popleft() IndexError: pop from an empty deque During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/jenkins/workspace/gate-nova-python34/nova/tests/unit/virt/xenapi/test_vmops.py", line 1044, in test_set_bootable self.vmops.set_bootable(self.instance, True) File "/home/jenkins/workspace/gate-nova-python34/nova/virt/xenapi/vmops.py", line 1621, in set_bootable vm_ref = self._get_vm_opaque_ref(instance) File "/home/jenkins/workspace/gate-nova-python34/nova/virt/xenapi/vmops.py", line 824, in _get_vm_opaque_ref vm_ref = vm_utils.lookup(self._session, instance['name'], check_rescue) File "/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/mox3/mox.py", line 814, in __call__ return mock_method(*params, **named_params) File "/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/mox3/mox.py", line 1113, in __call__ expected_method = self._VerifyMethodCall() File "/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/mox3/mox.py", line 1169, in _VerifyMethodCall expected = self._PopNextMethod() File "/home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/mox3/mox.py", line 1155, in _PopNextMethod raise UnexpectedMethodCallError(self, None) mox3.mox.UnexpectedMethodCallError: Unexpected method call function.__call__(, 'test', False) -> None 7 hits in 7 days, check and gate, py34 only, this is just mox3 being racy on py34. ** Affects: nova Importance: Undecided Status: Confirmed ** Tags: py34 testing xenserver ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1526369 Title: nova.tests.unit.virt.xenapi.test_vmops.BootableTestCase.test_set_bootable is racy on py34 Status in OpenStack Compute (nova): Confirmed Bug description: http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22mox3.mox.UnexpectedMethodCallError:%20Unexpected%20method%20call%20function.__call__(%3Cnova.virt.xenapi.client.session.XenAPISession%5C%22%20AND%20tags:%5C%22console%5C%22%20AND%20build_name:%5C %22gate-nova-python34%5C%22 ft1.7942: nova.tests.unit.virt.xenapi.test_vmops.BootableTestCase.test_set_bootable_StringException: Empty attachments: stdout pythonlogging:'': {{{2015-12-15 13:33:23,562 WARNING [oslo_reports.guru_meditation_report] Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be registered in a future release, so please use SIGUSR2 to generate reports.}}} stderr: {{{ /home/jenkins/workspace/gate-nova-python34/.tox/py34/lib/python3.4/site-packages/pkg_resources/__init__.py:213: RuntimeWarning: You have iterated over the result of pkg_resources.parse_version. This is a legacy behavior which is inconsistent with the new version class introduced in setuptools 8.0. In most cases, conversion to a tuple is unnecessary. For comparison of versions, sort the Version instances directly. If you have another use case requiring the tuple, please file a bug with the setuptools project describing that need. stacklevel=1, }}} Traceback (most recent call last): File "/home/jenkins/workspace/gate-nova-python34
[Yahoo-eng-team] [Bug 1525423] Re: get_networks performance hindered by segment lookups
Reviewed: https://review.openstack.org/256846 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=806e67538fbea49530aa0eedb75694cd8bad439d Submitter: Jenkins Branch:master commit 806e67538fbea49530aa0eedb75694cd8bad439d Author: Kevin Benton Date: Fri Dec 11 10:55:38 2015 -0800 Batch db segment retrieval A net-list operation was calling extend_network_dict_provider for each network individually which would result in a database call for each network. This adds a new call in the manager to extend multiple networks at once and then it adds a bulk version of get_network_segments that it calls. Now 1 net list of any number of networks will only result in 1 segment DB call. Change-Id: I2543b3bdbb178ee4bb8d1288e9a27af1c5c8c8b4 Closes-Bug: #1525423 Partial-Bug: #1513782 ** Changed in: neutron Status: In Progress => 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/1525423 Title: get_networks performance hindered by segment lookups Status in neutron: Fix Released Bug description: During the get_networks method of ML2, we iterate over each network and do a database call to lookup the segments for that network. This scales the number of database calls linearly with the number of retrieved networks. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525423/+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 1526462] [NEW] Need support for OpenDirectory in LDAP driver
Public bug reported: It is necessary to support Apple OpenDirectory as the backend for Keystone Identity. OpenDirectory uses a concept of POSIX groups, when the entities of users in the groups are represented as UIDs, not full DNs: dn: cn=group1, cn=groups,dc=domain,dc=com memberUid: user1 memberUid: user2 while in the driver of LDAP it is hardcoded that the entities could be only full DNs, like: dn: cn=group1, cn=groups,dc=domain,dc=com memberUid: uid=user1,cn=users,dc=domain,dc=com memberUid: uid=user2,cn=users,dc=domain,dc=com Because of this reason it is impossible to use groups in Keystone and we cannot assign the roles to the Keystone groups - Keystone doesn't recognize any user to be a part of any group. When it checks the roles, it searches for the direct user's assignments, and then for any groups which the user can be a member of. So by default the search returns nothing. We have to have an additional parameter in the config where we specify the type of the entity in the groups - whether is it currently a dn or an id. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1526462 Title: Need support for OpenDirectory in LDAP driver Status in OpenStack Identity (keystone): New Bug description: It is necessary to support Apple OpenDirectory as the backend for Keystone Identity. OpenDirectory uses a concept of POSIX groups, when the entities of users in the groups are represented as UIDs, not full DNs: dn: cn=group1, cn=groups,dc=domain,dc=com memberUid: user1 memberUid: user2 while in the driver of LDAP it is hardcoded that the entities could be only full DNs, like: dn: cn=group1, cn=groups,dc=domain,dc=com memberUid: uid=user1,cn=users,dc=domain,dc=com memberUid: uid=user2,cn=users,dc=domain,dc=com Because of this reason it is impossible to use groups in Keystone and we cannot assign the roles to the Keystone groups - Keystone doesn't recognize any user to be a part of any group. When it checks the roles, it searches for the direct user's assignments, and then for any groups which the user can be a member of. So by default the search returns nothing. We have to have an additional parameter in the config where we specify the type of the entity in the groups - whether is it currently a dn or an id. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1526462/+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 1526413] [NEW] test_app_using_ipv6_and_ssl fails with requests 2.9.0
Public bug reported: http://logs.openstack.org/50/257950/1/check/gate-nova- python27/6dfe685/testr_results.html.gz ft1.13019: nova.tests.unit.test_wsgi.TestWSGIServerWithSSL.test_app_using_ipv6_and_ssl_StringException: Empty attachments: stdout pythonlogging:'': {{{ 2015-12-15 15:55:06,381 WARNING [oslo_reports.guru_meditation_report] Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be registered in a future release, so please use SIGUSR2 to generate reports. 2015-12-15 15:55:06,383 INFO [nova.wsgi] fake_ssl listening on ::1:54837 2015-12-15 15:55:06,390 INFO [nova.fake_ssl.wsgi.server] (6121) wsgi starting up on https://::1:54837/ }}} stderr: {{{ /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning. SNIMissingWarning /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning. InsecurePlatformWarning }}} Traceback (most recent call last): File "nova/tests/unit/test_wsgi.py", line 333, in test_app_using_ipv6_and_ssl verify=os.path.join(SSL_CERT_DIR, 'ca.crt')) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py", line 67, in get return request('get', url, params=params, **kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/api.py", line 53, in request return session.request(method=method, url=url, **kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py", line 468, in request resp = self.send(prep, **send_kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/sessions.py", line 576, in send r = adapter.send(request, **kwargs) File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/adapters.py", line 447, in send raise SSLError(e, request=request) requests.exceptions.SSLError: hostname '[::1]' doesn't match either of 'localhost', 'ip6-localhost', '127.0.0.1', '::1' http://logstash.openstack.org/#dashboard/file/logstash.json?query=message:%5C%22requests.exceptions.SSLError:%20hostname%20'%5B::1%5D'%20doesn't%20match%20either%20of%20'localhost',%20'ip6-localhost',%20'127.0.0.1',%20'::1'%5C%22%20AND%20tags:%5C%22console%5C%22 just started today when requests 2.9.0 was released: https://pypi.python.org/pypi/requests/2.9.0 ** Affects: nova Importance: Critical Status: Confirmed ** Tags: api testing ** Changed in: nova Status: New => Confirmed ** Changed in: nova Importance: Undecided => Critical -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1526413 Title: test_app_using_ipv6_and_ssl fails with requests 2.9.0 Status in OpenStack Compute (nova): Confirmed Bug description: http://logs.openstack.org/50/257950/1/check/gate-nova- python27/6dfe685/testr_results.html.gz ft1.13019: nova.tests.unit.test_wsgi.TestWSGIServerWithSSL.test_app_using_ipv6_and_ssl_StringException: Empty attachments: stdout pythonlogging:'': {{{ 2015-12-15 15:55:06,381 WARNING [oslo_reports.guru_meditation_report] Guru mediation now registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be registered in a future release, so please use SIGUSR2 to generate reports. 2015-12-15 15:55:06,383 INFO [nova.wsgi] fake_ssl listening on ::1:54837 2015-12-15 15:55:06,390 INFO [nova.fake_ssl.wsgi.server] (6121) wsgi starting up on https://::1:54837/ }}} stderr: {{{ /home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning. SNIMissingWarning
[Yahoo-eng-team] [Bug 1525002] Re: The ironic driver needs to scale back how many errors it traces out
Reviewed: https://review.openstack.org/256375 Committed: https://git.openstack.org/cgit/openstack/python-ironicclient/commit/?id=8224859c02f525fa3b7dbe917d56b889b0dbb073 Submitter: Jenkins Branch:master commit 8224859c02f525fa3b7dbe917d56b889b0dbb073 Author: Dmitry Tantsur Date: Fri Dec 11 12:38:39 2015 +0100 Scale back on how many warnings we issue * Remove "Request returned failure status" warning, it does not carry any helpful information for an operator (or anyone). * Demote retry warnings to debug level. Retrying is essentially a normal thing in the real world, and currently we're spamming logs with warnings. http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic-agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE Change-Id: I6c40581b9dc5ab1fe3af4b882ede17a13edacc66 Closes-Bug: #1525002 ** Changed in: python-ironicclient Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1525002 Title: The ironic driver needs to scale back how many errors it traces out Status in Ironic: In Progress Status in OpenStack Compute (nova): Confirmed Status in python-ironicclient: Fix Released Bug description: The amount of tracing in this n-cpu log is a bit much: http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic- agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE Like these warnings: http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic- agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE#_2015-12-10_16_11_48_799 2015-12-10 16:11:48.798 WARNING ironicclient.common.http [req-94077ab9-5adf-4720-9fb8-2e027dde9b72 tempest-BaremetalBasicOps-1285004585 tempest-BaremetalBasicOps-1966762451] Request returned failure status. 2015-12-10 16:11:48.799 WARNING ironicclient.common.http [req-94077ab9-5adf-4720-9fb8-2e027dde9b72 tempest-BaremetalBasicOps-1285004585 tempest-BaremetalBasicOps-1966762451] Error contacting Ironic server: Node 1 is locked by host localhost, please retry after the current operation is completed. Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 150, in inner return func(*args, **kwargs) File "/opt/stack/new/ironic/ironic/conductor/manager.py", line 1519, in update_port purpose='port update') as task: File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 152, in acquire driver_name=driver_name, purpose=purpose) File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 222, in __init__ self.release_resources() File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 204, in __exit__ six.reraise(self.type_, self.value, self.tb) File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 203, in __init__ self._lock() File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 243, in _lock reserve_node() File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 49, in wrapped_f return Retrying(*dargs, **dkw).call(f, *args, **kw) File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 212, in call raise attempt.get() File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 247, in get six.reraise(self.value[0], self.value[1], self.value[2]) File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 200, in call attempt = Attempt(fn(*args, **kwargs), attempt_number, False) File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 236, in reserve_node self.node_id) File "/opt/stack/new/ironic/ironic/objects/node.py", line 260, in reserve db_node = cls.dbapi.reserve_node(tag, node_id) File "/opt/stack/new/ironic/ironic/db/sqlalchemy/api.py", line 226, in reserve_node host=node['reservation']) NodeLocked: Node 1 is locked by host localhost, please retry after the current operation is completed. (HTTP 409). Attempt 1 of 61 UPD from dtantsur: The traceback has nothing to do with ironic client or driver. It gets added somewhere between ironic conductor and API levels. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1525002/+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 1424096] Re: DVR routers attached to shared networks aren't being unscheduled from a compute node after deleting the VMs using the shared net
I faced the bug while reworking unit tests into functional tests: when performing steps described in the description I get: 2015-12-15 17:41:23,484ERROR [neutron.callbacks.manager] Error during notification for neutron.db.l3_dvrscheduler_db._notify_port_delete port, after_delete Traceback (most recent call last): File "neutron/callbacks/manager.py", line 141, in _notify_loop callback(resource, event, trigger, **kwargs) File "neutron/db/l3_dvrscheduler_db.py", line 485, in _notify_port_delete context, router['agent_id'], router['router_id']) File "neutron/db/l3_dvrscheduler_db.py", line 439, in remove_router_from_l3_agent router = self.get_router(context, router_id) File "neutron/db/l3_db.py", line 451, in get_router router = self._get_router(context, id) File "neutron/db/l3_db.py", line 137, in _get_router raise l3.RouterNotFound(router_id=router_id) RouterNotFound: Router 7d52836b-8fe5-4417-842f-3cbe0920c89c could not be found and router is not removed from host which has no more dvr serviceable ports. Looks like we also need admin context in order to remove admin router from a host when non-admin tenant removes last dvr serviceable port on a shared network. ** Changed in: neutron Status: Fix Released => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1424096 Title: DVR routers attached to shared networks aren't being unscheduled from a compute node after deleting the VMs using the shared net Status in neutron: Confirmed Status in neutron juno series: Fix Released Status in neutron kilo series: New Bug description: As the administrator, a DVR router is created and attached to a shared network. The administrator also created the shared network. As a non-admin tenant, a VM is created with the port using the shared network. The only VM using the shared network is scheduled to a compute node. When the VM is deleted, it is expected the qrouter namespace of the DVR router is removed. But it is not. This doesn't happen with routers attached to networks that are not shared. The environment consists of 1 controller node and 1 compute node. Routers having the problem are created by the administrator attached to shared networks that are also owned by the admin: As the administrator, do the following commands on a setup having 1 compute node and 1 controller node: 1. neutron net-create shared-net -- --shared True Shared net's uuid is f9ccf1f9-aea9-4f72-accc-8a03170fa242. 2. neutron subnet-create --name shared-subnet shared-net 10.0.0.0/16 3. neutron router-create shared-router Router's UUID is ab78428a-9653-4a7b-98ec-22e1f956f44f. 4. neutron router-interface-add shared-router shared-subnet 5. neutron router-gateway-set shared-router public As a non-admin tenant (tenant-id: 95cd5d9c61cf45c7bdd4e9ee52659d13), boot a VM using the shared-net network: 1. neutron net-show shared-net +-+--+ | Field | Value| +-+--+ | admin_state_up | True | | id | f9ccf1f9-aea9-4f72-accc-8a03170fa242 | | name| shared-net | | router:external | False| | shared | True | | status | ACTIVE | | subnets | c4fd4279-81a7-40d6-a80b-01e8238c1c2d | | tenant_id | 2a54d6758fab47f4a2508b06284b5104 | +-+--+ At this point, there are no VMs using the shared-net network running in the environment. 2. Boot a VM that uses the shared-net network: nova boot ... --nic net-id=f9ccf1f9-aea9-4f72-accc-8a03170fa242 ... vm_sharednet 3. Assign a floating IP to the VM "vm_sharednet" 4. Delete "vm_sharednet". On the compute node, the qrouter namespace of the shared router (qrouter-ab78428a-9653-4a7b-98ec-22e1f956f44f) is left behind stack@DVR-CN2:~/DEVSTACK/manage$ ip netns qrouter-ab78428a-9653-4a7b-98ec-22e1f956f44f ... This is consistent with the output of "neutron l3-agent-list-hosting-router" command. It shows the router is still being hosted on the compute node. $ neutron l3-agent-list-hosting-router ab78428a-9653-4a7b-98ec-22e1f956f44f +--+++---+ | id | host | admin_state_up | alive | +--+++---+ | 42f12eb0-51bc-4861-928a-48de51ba7ae1 | DVR-Controller | True | :-) | | ff869dc5-d39c-464d-86f3-112b55ec1c
[Yahoo-eng-team] [Bug 1522199] Re: Functional test_ipwrapper_get_device_by_ip fails with new kernels
Reviewed: https://review.openstack.org/254801 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8ddeb4be9e32e5cefab8324d0cbf9cecead1f808 Submitter: Jenkins Branch:master commit 8ddeb4be9e32e5cefab8324d0cbf9cecead1f808 Author: John Schwarz Date: Tue Dec 8 16:17:46 2015 +0200 Ignore possible suffix in iproute commands. Closes-Bug: #1522199 Change-Id: I14815abd9345edb079e3331cbe2465ad22a0d4c3 ** Changed in: neutron Status: In Progress => 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/1522199 Title: Functional test_ipwrapper_get_device_by_ip fails with new kernels Status in neutron: Fix Released Bug description: Trace: http://paste.openstack.org/show/480710/ The test creates a device via: sudo ip tuntap add test223ef12 mode tap Which on my system (Fedora 22) results in a device called: test223ef12@NONE And the test fails to compare 'test223ef12' to 'test223ef12@NONE'. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1522199/+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 968696] Re: "admin"-ness not properly scoped
Reviewed: https://review.openstack.org/240720 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=9804081a80ef815a86407a64f967986a7bf9ba25 Submitter: Jenkins Branch:master commit 9804081a80ef815a86407a64f967986a7bf9ba25 Author: Adam Young Date: Sun Nov 1 11:55:45 2015 -0500 Updated Cloudsample Uses configuration options to determine if a token is for the admin project and should be granted admin privileges. Closes-Bug: 968696 Change-Id: Ib23452e171dc90115c77fa5a4b9dc4649054eb0e ** Changed in: keystone Status: In Progress => 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/968696 Title: "admin"-ness not properly scoped Status in Cinder: Fix Released Status in Glance: New Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (keystone): Fix Released Status in neutron: Triaged Status in OpenStack Compute (nova): Confirmed Status in puppet-keystone: New Bug description: Fact: Keystone's rbac model grants roles to users on specific tenants, and post-keystone redux, there are no longer "global" roles. Problem: Granting a user an "admin" role on ANY tenant grants them unlimited "admin"-ness throughout the system because there is no differentiation between a scoped "admin"-ness and a global "admin"-ness. I don't have a specific solution to advocate, but being an admin on *any* tenant simply *cannot* allow you to administer all of keystone. Steps to reproduce (from Horizon, though you could do this with the CLI, too): 1. User A (existing admin) creates Project B and User B. 2. User A adds User B to Project B with the admin role on Project B. 3. User B logs in and now has unlimited admin rights not only to view things in the dashboard, but to take actions like creating new projects and users, managing existing projects and users, etc. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/968696/+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 1370037] Re: bulk termination of instances
** Changed in: horizon Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1370037 Title: bulk termination of instances Status in OpenStack Dashboard (Horizon): Invalid Bug description: while terminating a bulk of instances from the horizon, the first instance termination failed, the other instances all stayed in available status. Steps to Reproduce: 1. Delete a bulk of instances 2. The first deletion process should fail & the instance status should turn to Error Actual results: The other instances are not been terminated Expected results: The termination of the instances should continue to the other instances To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1370037/+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 1526300] [NEW] openstack client in Mistal can't support to change the endpoint_type
Public bug reported: In my OpenStack environment, publicURL of all the OpenStack services are based on HTTPS, and internalURL is based on HTTP. I want Mistral to use internalURL to access other OpenStack services, but looks like the "endpoint_type" is hard coded as shown here: NovaAction._get_client def _get_client(self): ctx = context.ctx() LOG.debug("Nova action security context: %s" % ctx) keystone_endpoint = keystone_utils.get_keystone_endpoint_v2() nova_endpoint = keystone_utils.get_endpoint_for_project('nova') client = self._client_class( username=None, api_key=None, endpoint_type='publicURL', < Here it is hard coded. service_type='compute', auth_token=ctx.auth_token, tenant_id=ctx.project_id, region_name=keystone_endpoint.region, auth_url=keystone_endpoint.url ) client.client.management_url = keystone_utils.format_url( nova_endpoint.url, {'tenant_id': ctx.project_id} ) return client If it can be configurable, it will be great. Thanks, Tony ** Affects: mistral Importance: Undecided Status: New ** Project changed: horizon => mistral -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1526300 Title: openstack client in Mistal can't support to change the endpoint_type Status in Mistral: New Bug description: In my OpenStack environment, publicURL of all the OpenStack services are based on HTTPS, and internalURL is based on HTTP. I want Mistral to use internalURL to access other OpenStack services, but looks like the "endpoint_type" is hard coded as shown here: NovaAction._get_client def _get_client(self): ctx = context.ctx() LOG.debug("Nova action security context: %s" % ctx) keystone_endpoint = keystone_utils.get_keystone_endpoint_v2() nova_endpoint = keystone_utils.get_endpoint_for_project('nova') client = self._client_class( username=None, api_key=None, endpoint_type='publicURL', < Here it is hard coded. service_type='compute', auth_token=ctx.auth_token, tenant_id=ctx.project_id, region_name=keystone_endpoint.region, auth_url=keystone_endpoint.url ) client.client.management_url = keystone_utils.format_url( nova_endpoint.url, {'tenant_id': ctx.project_id} ) return client If it can be configurable, it will be great. Thanks, Tony To manage notifications about this bug go to: https://bugs.launchpad.net/mistral/+bug/1526300/+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 1526279] Re: murano-agent can't ship binary file to nova instance
** Project changed: horizon => murano -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1526279 Title: murano-agent can't ship binary file to nova instance Status in Murano: New Bug description: 1. I want to use murano-agent to ship rpm package to nova instance, and got the following error: 2015-12-15 10:05:33.735 1 ERROR murano.common.engine [-] exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xed in position 0: ordinal not in range(128) Traceback (most recent call last): File "/tmp/murano-packages-cache/585c671065534988ba95fc81fe9dcc2e/3e0ed1ccc50f4e189612969273768666/Classes/Environment.yaml", line 82:9 in method deploy of class io.murano.Environment $.applications.pselect($.deploy()) File "/tmp/murano-packages-cache/585c671065534988ba95fc81fe9dcc2e/f69c326e5cc5401881a7701f300f319b/Classes/MRF.yaml", line 249:13 in method deploy of class com.alu.apps.mrf.MRF $.mistralAgent.call($template, $resources) File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 45 in method evaluate return value(context) File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py", line 82 in method __call__ return self._parsed_expression.evaluate(context=context) File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 165 in method evaluate return self(utils.NO_VALUE, context, self.engine) File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 156 in method __call__ return super(Statement, self).__call__(receiver, context, engine) File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 37 in method __call__ return context(self.name, engine, receiver, context)(*self.args) File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 in method data_context, use_convention, function_filter) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 in method call name, all_overloads, engine, receiver, data_context, args, kwargs) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 in method choose_overload args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args)) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 in method args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args)) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 113 in method and not isinstance(arg, expressions.Constant)) File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 37 in method __call__ return context(self.name, engine, receiver, context)(*self.args) File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 in method data_context, use_convention, function_filter) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 in method call result = delegate() File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 in method return lambda: delegate() File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 in method func six.iteritems(keyword_args))) File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_functions.py", line 140 in method op_dot return operator(ctx2, sender, expr) File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 290 in method func new_name, engine, new_receiver, new_context)(*args, **kwargs) File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 in method data_context, use_convention, function_filter) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 in method call result = delegate() File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 in method return lambda: delegate() File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 in method func six.iteritems(keyword_args))) File "/usr/lib/python2.7/site-packages/yaql/standard_library/system.py", line 34 in method op_dot return expr(receiver) File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 236 in method func engine, args, kwargs) File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 205 in method _call result = value(receiver, context, engine) File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 37 in method __call__ return context(self.name, engine, receiver, context)(*self.args) File "/usr/lib/python2.7/site-packages/yaql/language
[Yahoo-eng-team] [Bug 1207599] Re: Test failing due to latest version of openstack_auth
** Changed in: horizon/folsom Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1207599 Title: Test failing due to latest version of openstack_auth Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) folsom series: Fix Released Status in OpenStack Dashboard (Horizon) grizzly series: Fix Released Bug description: Horizon jobs are failing due to incompatibility with openstack_auth 2013-08-02 00:37:02.136 | == 2013-08-02 00:37:02.136 | ERROR: test_update_project_member_update_error_domain (openstack_dashboard.dashboards.admin.projects.tests.UpdateProjectWorkflowTests) 2013-08-02 00:37:02.136 | -- 2013-08-02 00:37:02.136 | Traceback (most recent call last): 2013-08-02 00:37:02.136 | File "/home/jenkins/workspace/gate-horizon-python26/openstack_dashboard/dashboards/admin/projects/tests.py", line 1242, in test_update_project_member_update_error_domain 2013-08-02 00:37:02.136 | self.test_update_project_member_update_error() 2013-08-02 00:37:02.136 | File "/home/jenkins/workspace/gate-horizon-python26/openstack_dashboard/test/helpers.py", line 77, in instance_stub_out 2013-08-02 00:37:02.137 | return fn(self) 2013-08-02 00:37:02.137 | File "/home/jenkins/workspace/gate-horizon-python26/openstack_dashboard/dashboards/admin/projects/tests.py", line 1232, in test_update_project_member_update_error 2013-08-02 00:37:02.137 | res = self.client.post(url, workflow_data) 2013-08-02 00:37:02.137 | File "/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/django/test/client.py", line 463, in post 2013-08-02 00:37:02.137 | response = super(Client, self).post(path, data=data, content_type=content_type, **extra) 2013-08-02 00:37:02.137 | File "/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/django/test/client.py", line 297, in post 2013-08-02 00:37:02.137 | return self.request(**r) 2013-08-02 00:37:02.137 | File "/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/django/test/client.py", line 424, in request 2013-08-02 00:37:02.137 | six.reraise(*exc_info) 2013-08-02 00:37:02.138 | File "/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/django/core/handlers/base.py", line 115, in get_response 2013-08-02 00:37:02.138 | response = callback(request, *callback_args, **callback_kwargs) 2013-08-02 00:37:02.138 | File "/home/jenkins/workspace/gate-horizon-python26/horizon/decorators.py", line 38, in dec 2013-08-02 00:37:02.138 | return view_func(request, *args, **kwargs) 2013-08-02 00:37:02.138 | File "/home/jenkins/workspace/gate-horizon-python26/horizon/decorators.py", line 84, in dec 2013-08-02 00:37:02.138 | if request.user.is_authenticated(): 2013-08-02 00:37:02.138 | File "/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py", line 189, in is_authenticated 2013-08-02 00:37:02.138 | return self.token is not None and check_token_expiration(self.token) 2013-08-02 00:37:02.138 | File "/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py", line 55, in check_token_expiration 2013-08-02 00:37:02.138 | if settings.USE_TZ and timezone.is_naive(expiration): 2013-08-02 00:37:02.139 | File "/home/jenkins/workspace/gate-horizon-python26/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py", line 272, in is_naive 2013-08-02 00:37:02.139 | return value.tzinfo is None or value.tzinfo.utcoffset(value) is None 2013-08-02 00:37:02.139 | AttributeError: 'str' object has no attribute 'tzinfo' To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1207599/+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 1308642] Re: Missing comma in the _attrs of Volume Resource Wrapper
** Changed in: horizon/icehouse Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1308642 Title: Missing comma in the _attrs of Volume Resource Wrapper Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) icehouse series: Fix Released Bug description: Missing comma after 'bootable' https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/cinder.py#L81 class Volume(BaseCinderAPIResourceWrapper): _attrs = ['id', 'name', 'description', 'size', 'status', 'created_at', 'volume_type', 'availability_zone', 'imageRef', 'bootable' 'snapshot_id', 'source_volid', 'attachments', 'tenant_name', 'os-vol-host-attr:host', 'os-vol-tenant-attr:tenant_id', 'metadata'] To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308642/+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 1526279] [NEW] murano-agent can't ship binary file to nova instance
Public bug reported: 1. I want to use murano-agent to ship rpm package to nova instance, and got the following error: 2015-12-15 10:05:33.735 1 ERROR murano.common.engine [-] exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xed in position 0: ordinal not in range(128) Traceback (most recent call last): File "/tmp/murano-packages-cache/585c671065534988ba95fc81fe9dcc2e/3e0ed1ccc50f4e189612969273768666/Classes/Environment.yaml", line 82:9 in method deploy of class io.murano.Environment $.applications.pselect($.deploy()) File "/tmp/murano-packages-cache/585c671065534988ba95fc81fe9dcc2e/f69c326e5cc5401881a7701f300f319b/Classes/MRF.yaml", line 249:13 in method deploy of class com.alu.apps.mrf.MRF $.mistralAgent.call($template, $resources) File "/usr/lib/python2.7/site-packages/murano/dsl/helpers.py", line 45 in method evaluate return value(context) File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_expression.py", line 82 in method __call__ return self._parsed_expression.evaluate(context=context) File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 165 in method evaluate return self(utils.NO_VALUE, context, self.engine) File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 156 in method __call__ return super(Statement, self).__call__(receiver, context, engine) File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 37 in method __call__ return context(self.name, engine, receiver, context)(*self.args) File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 in method data_context, use_convention, function_filter) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 49 in method call name, all_overloads, engine, receiver, data_context, args, kwargs) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 in method choose_overload args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args)) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 117 in method args = tuple(arg_evaluator(i, arg) for i, arg in enumerate(args)) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 113 in method and not isinstance(arg, expressions.Constant)) File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 37 in method __call__ return context(self.name, engine, receiver, context)(*self.args) File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 in method data_context, use_convention, function_filter) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 in method call result = delegate() File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 in method return lambda: delegate() File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 in method func six.iteritems(keyword_args))) File "/usr/lib/python2.7/site-packages/murano/dsl/yaql_functions.py", line 140 in method op_dot return operator(ctx2, sender, expr) File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 290 in method func new_name, engine, new_receiver, new_context)(*args, **kwargs) File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 in method data_context, use_convention, function_filter) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 in method call result = delegate() File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 in method return lambda: delegate() File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 in method func six.iteritems(keyword_args))) File "/usr/lib/python2.7/site-packages/yaql/standard_library/system.py", line 34 in method op_dot return expr(receiver) File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 236 in method func engine, args, kwargs) File "/usr/lib/python2.7/site-packages/yaql/language/yaqltypes.py", line 205 in method _call result = value(receiver, context, engine) File "/usr/lib/python2.7/site-packages/yaql/language/expressions.py", line 37 in method __call__ return context(self.name, engine, receiver, context)(*self.args) File "/usr/lib/python2.7/site-packages/yaql/language/contexts.py", line 65 in method data_context, use_convention, function_filter) File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 51 in method call result = delegate() File "/usr/lib/python2.7/site-packages/yaql/language/runner.py", line 142 in method return lambda: delegate() File "/usr/lib/python2.7/site-packages/yaql/language/specs.py", line 341 in method func
[Yahoo-eng-team] [Bug 1478471] Re: neutron can't use internal nova-api url for notification with v3 auth
Reviewed: https://review.openstack.org/254900 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=7dad96deb4ae66509d968465bcd1c852c6743bc1 Submitter: Jenkins Branch:master commit 7dad96deb4ae66509d968465bcd1c852c6743bc1 Author: Jeremy McDermond Date: Tue Dec 8 10:14:09 2015 -0800 Add option for nova endpoint type When the neutron notification to nova was updated to use novaclient the nova_url parameter was disabled. This prevents administrators from using anything but the publicURL as the proper endpoint to notify nova. This patch adds an option to pass on to novaclient for the endpoint_type so that the administrator can set the notification url to public, internal or admin. Change-Id: I405f76199cab6b8c8895f98419f79cd74cad Closes-Bug: #1478471 DocImpact: Need to add a new option to the neutron configuration reference. ** Changed in: neutron Status: In Progress => 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/1478471 Title: neutron can't use internal nova-api url for notification with v3 auth Status in neutron: Fix Released Bug description: Hi! When the v3 auth plugin is used for notifying nova on changes, the config parameter nova_url is ignored and neutron uses public endpoint automatically. If internalURL and publicURL are not the same, and publicURL is not accessible for internal services, than the notification will fail and so will VM creation. I tried to look for any config parmeter to change this behavior, but couldn't find any. OS: Ubuntu 14.04 Neutron version: 1:2015.1.0-0ubuntu1~cloud0 my nova endpoints: +--+-+ | Field| Value | +--+-+ | adminurl | http://192.168.56.10:8774/v2/%(tenant_id)s | | enabled | True| | id | 3706c3fe985c4219a145a7ec83c14955| | internalurl | http://192.168.56.10:8774/v2/%(tenant_id)s | | publicurl| https://192.168.55.10:8774/v2/%(tenant_id)s | | region | labor | | service_id | ebc286c9356449819d2c7a7a5fbd1c77| | service_name | nova| | service_type | compute | +--+-+ partial log: 2015-07-23 11:31:06.021 24522 DEBUG keystoneclient.auth.identity.v3 [-] Making authentication request to http://192.168.56.10:35357/v3/auth/tokens get_auth_ref /usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/v3.py:125 2015-07-23 11:31:06.385 24522 DEBUG keystoneclient.session [-] REQ: curl -g -i -X POST https://192.168.55.10:8774/v2/d239fb491e944da39e430174dc5fd33e/os-server-external-events -H "User-Agent: python-novaclient" -H "Content-Type: applicat$ 2015-07-23 11:31:06.443 24522 ERROR neutron.notifiers.nova [-] Failed to notify nova on events: [{'status': 'completed', 'tag': u'2a6ce600-1c57-4f91-a17e-1623adf9e1ee', 'name': 'network-vif-plugged', 'server_uuid': u'f77b2756-99ed-4259-b$ 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova Traceback (most recent call last): 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova File "/usr/lib/python2.7/dist-packages/neutron/notifiers/nova.py", line 243, in send_events 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova batched_events) 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova File "/usr/lib/python2.7/dist-packages/novaclient/v2/contrib/server_external_events.py", line 39, in create 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova return_raw=True) 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova File "/usr/lib/python2.7/dist-packages/novaclient/base.py", line 152, in _create 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova _resp, body = self.api.client.post(url, body=body) 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova File "/usr/lib/python2.7/dist-packages/keystoneclient/adapter.py", line 170, in post 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova return self.request(url, 'POST', **kwargs) 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 89, in request 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova **kwargs) 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova File "/usr/lib/python2.7/dist-packages/keystoneclient/adapter.py", line 200, in request 2015-07-23 11:31:06.443 24522 TRACE neutron.notifiers.nova resp = super(LegacyJsonAdapter, self).request(*args, **kwargs) 2015-0
[Yahoo-eng-team] [Bug 1526245] [NEW] Add option for nova endpoint type
Public bug reported: https://review.openstack.org/254900 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 7dad96deb4ae66509d968465bcd1c852c6743bc1 Author: Jeremy McDermond Date: Tue Dec 8 10:14:09 2015 -0800 Add option for nova endpoint type When the neutron notification to nova was updated to use novaclient the nova_url parameter was disabled. This prevents administrators from using anything but the publicURL as the proper endpoint to notify nova. This patch adds an option to pass on to novaclient for the endpoint_type so that the administrator can set the notification url to public, internal or admin. Change-Id: I405f76199cab6b8c8895f98419f79cd74cad Closes-Bug: #1478471 DocImpact: Need to add a new option to the neutron configuration reference. ** Affects: neutron Importance: Undecided Status: New ** Tags: 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/1526245 Title: Add option for nova endpoint type Status in neutron: New Bug description: https://review.openstack.org/254900 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit 7dad96deb4ae66509d968465bcd1c852c6743bc1 Author: Jeremy McDermond Date: Tue Dec 8 10:14:09 2015 -0800 Add option for nova endpoint type When the neutron notification to nova was updated to use novaclient the nova_url parameter was disabled. This prevents administrators from using anything but the publicURL as the proper endpoint to notify nova. This patch adds an option to pass on to novaclient for the endpoint_type so that the administrator can set the notification url to public, internal or admin. Change-Id: I405f76199cab6b8c8895f98419f79cd74cad Closes-Bug: #1478471 DocImpact: Need to add a new option to the neutron configuration reference. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1526245/+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 1526199] [NEW] volumes have no attribute tenant_name gives error
Public bug reported: Volumes have no attribute tenant_name, gives the error like: The attribute tenant_name doesn't exist on . ** Affects: horizon Importance: Undecided Assignee: zhu.rong (zhu-rong) Status: In Progress ** Changed in: horizon Assignee: (unassigned) => zhu.rong (zhu-rong) ** Description changed: - Volumes have no attribute version, gives the error like: + Volumes have no attribute tenant_name, gives the error like: The attribute tenant_name doesn't exist on . -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1526199 Title: volumes have no attribute tenant_name gives error Status in OpenStack Dashboard (Horizon): In Progress Bug description: Volumes have no attribute tenant_name, gives the error like: The attribute tenant_name doesn't exist on . To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1526199/+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