[Yahoo-eng-team] [Bug 1535215] [NEW] AttributeError: 'module' object has no attribute 'ClientException'
Public bug reported: Launch instance give the error: File "/home/openstack/horizon-murano/horizon/utils/memoized.py", line 90, in wrapped value = cache[key] = func(*args, **kwargs) File "/home/openstack/horizon-murano/openstack_dashboard/usage/quotas.py", line 371, in tenant_quota_usages tenant_id=tenant_id): File "/home/openstack/horizon-murano/openstack_dashboard/usage/quotas.py", line 171, in get_tenant_quota_data tenant_id=tenant_id) File "/home/openstack/horizon-murano/openstack_dashboard/usage/quotas.py", line 150, in _get_quota_data except cinder.ClientException: AttributeError: 'module' object has no attribute 'ClientException' ** Affects: horizon Importance: Undecided Assignee: zhurong (zhu-rong) Status: New ** Changed in: horizon Assignee: (unassigned) => zhurong (zhu-rong) -- 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/1535215 Title: AttributeError: 'module' object has no attribute 'ClientException' Status in OpenStack Dashboard (Horizon): New Bug description: Launch instance give the error: File "/home/openstack/horizon-murano/horizon/utils/memoized.py", line 90, in wrapped value = cache[key] = func(*args, **kwargs) File "/home/openstack/horizon-murano/openstack_dashboard/usage/quotas.py", line 371, in tenant_quota_usages tenant_id=tenant_id): File "/home/openstack/horizon-murano/openstack_dashboard/usage/quotas.py", line 171, in get_tenant_quota_data tenant_id=tenant_id) File "/home/openstack/horizon-murano/openstack_dashboard/usage/quotas.py", line 150, in _get_quota_data except cinder.ClientException: AttributeError: 'module' object has no attribute 'ClientException' To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1535215/+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 1535218] [NEW] NotFound maybe returned by keystone
Public bug reported:
How to reproduce:
1. Remove nova_admin_tenant_id from /etc/neutron/neutron.conf
2. Boot an instance
Expected log:
Keystone returned NotFound for event:...
Actual log:
Nova returned NotFound for event:...
Related log (we have not fixed bug 1309187 yet) :
2016-01-15 13:38:17.449 3509717 ERROR neutron.notifiers.nova [-] Failed to
notify nova on events: [{'status': 'completed', 'tag':
u'55524e69-9bf8-408e-bb9c-4239084837e9', 'name': 'network-vif-unplugged',
'server_uuid': u'a7466a5f-ca73-4ded-b0c3-77374f676b26'}]
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova Traceback (most
recent call last):
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/neutron/notifiers/nova.py", line 223, in
send_events
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova batched_events)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/novaclient/v1_1/contrib/server_external_events.py",
line 39, in create
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova
return_raw=True)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/novaclient/base.py", line 152, in _create
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova _resp, body =
self.api.client.post(url, body=body)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/novaclient/client.py", line 312, in post
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova return
self._cs_request(url, 'POST', **kwargs)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/novaclient/client.py", line 275, in
_cs_request
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova
self.authenticate()
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/novaclient/client.py", line 408, in
authenticate
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova auth_url =
self._v2_auth(auth_url)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/novaclient/client.py", line 495, in _v2_auth
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova return
self._authenticate(url, body)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/novaclient/client.py", line 508, in
_authenticate
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova **kwargs)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/novaclient/client.py", line 268, in
_time_request
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova resp, body =
self.request(url, method, **kwargs)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/novaclient/client.py", line 262, in request
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova raise
exceptions.from_response(resp, body, url, method)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova NotFound: Not
found (HTTP 404)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova
** Affects: neutron
Importance: Undecided
Status: New
** Description changed:
How to reproduce:
-1. Remove nova_admin_tenant_id from /etc/neutron/neutron.conf
-2. Boot an instance
+ 1. Remove nova_admin_tenant_id from /etc/neutron/neutron.conf
+ 2. Boot an instance
- Expected:
- Keystone returned NotFound for event:...
+ Expected log:
+ Keystone returned NotFound for event:...
- Actual:
-Nova returned NotFound for event:...
+ Actual log:
+ Nova returned NotFound for event:...
Related log (we have not fixed bug 1309187 yet) :
- 2016-01-15 13:38:17.449 3509717 ERROR neutron.notifiers.nova [-] Failed
to notify nova on events: [{'status': 'completed', 'tag':
u'55524e69-9bf8-408e-bb9c-4239084837e9', 'name': 'network-vif-unplugged',
'server_uuid': u'a7466a5f-ca73-4ded-b0c3-77374f676b26'}]
+ 2016-01-15 13:38:17.449 3509717 ERROR neutron.notifiers.nova [-] Failed to
notify nova on events: [{'status': 'completed', 'tag':
u'55524e69-9bf8-408e-bb9c-4239084837e9', 'name': 'network-vif-unplugged',
'server_uuid': u'a7466a5f-ca73-4ded-b0c3-77374f676b26'}]
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova Traceback (most
recent call last):
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/neutron/notifiers/nova.py", line 223, in
send_events
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova
batched_events)
2016-01-15 13:38:17.449 3509717 TRACE neutron.notifiers.nova File
"/usr/lib/python2.6/site-packages/novaclient/v1_1/contrib/server_external_events.py",
line 39, in create
2016-01-15 1
[Yahoo-eng-team] [Bug 1535224] [NEW] meta data of nova instance with case sensitive has problem when deleting
Public bug reported:
[Summary]
meta data of nova instance with case sensitive has problem when deleting
[Topo]
devstack all-in-one node
[Description and expect result]
can delete case sensitive meta one by one
[Reproduceable or not]
reproduceable
[Recreate Steps]
1) set 4 metas for an instance, if ignore case, they have same string:
stack@45-59:~/devstack$ nova meta inst set abc=1 Abc=2 ABc=3 ABC=4
stack@45-59:~/devstack$ nova show inst
+--++
| Property | Value
|
+--++
| OS-DCF:diskConfig| MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-SRV-ATTR:host | 45-59
|
| OS-EXT-SRV-ATTR:hostname | inst
|
| OS-EXT-SRV-ATTR:hypervisor_hostname | 45-59
|
| OS-EXT-SRV-ATTR:instance_name| instance-0001
|
| OS-EXT-SRV-ATTR:kernel_id| 13716aa6-6110-4b26-9eb4-71f053c14b3d
|
| OS-EXT-SRV-ATTR:launch_index | 0
|
| OS-EXT-SRV-ATTR:ramdisk_id | 4c1870c0-520c-4423-8a6b-72e1839eeb76
|
| OS-EXT-SRV-ATTR:reservation_id | r-wc29hykh
|
| OS-EXT-SRV-ATTR:root_device_name | /dev/vda
|
| OS-EXT-SRV-ATTR:user_data| -
|
| OS-EXT-STS:power_state | 1
|
| OS-EXT-STS:task_state| -
|
| OS-EXT-STS:vm_state | active
|
| OS-SRV-USG:launched_at | 2016-01-18T15:34:42.00
|
| OS-SRV-USG:terminated_at | -
|
| accessIPv4 |
|
| accessIPv6 |
|
| config_drive | True
|
| created | 2016-01-18T15:34:31Z
|
| flavor | m1.tiny (1)
|
| hostId |
8b5dd2a2c67716f40b65b8796dcb25c62f7522764e2dc7f9ff88ea7b |
| id | c2f19b32-cf99-4f6f-b9aa-fcf7246ff189
|
| image| cirros-0.3.4-x86_64-uec
(03ada996-9688-471f-ab8c-a9cc18175e2e) |
| key_name | -
|
| locked | False
|
| metadata | {"abc": "1", "Abc": "2", "ABC": "3",
"ABc": "4"} |
| name | inst
|
| net1 network | 1.0.0.3
|
| os-extended-volumes:volumes_attached | []
|
| progress | 0
|
| security_groups | default
|
| status | ACTIVE
|
| tenant_id| e88840d981e2457595baed077ed2aac8
|
| updated | 2016-01-18T15:43:48Z
|
| user_id | 9d619f44512a4289a670332300f1089c
|
+--++
2) if delete one of them, all are deleted:ISSUE
stack@45-59:~/devstack$ nova meta inst delete abc
stack@45-59:~/devstack$ nova show inst
+-
[Yahoo-eng-team] [Bug 1534030] Re: Add tox debug env
Reviewed: https://review.openstack.org/266020 Committed: https://git.openstack.org/cgit/openstack/magnum/commit/?id=97e3a6b897f8233c155c7c454c893b0976f87a06 Submitter: Jenkins Branch:master commit 97e3a6b897f8233c155c7c454c893b0976f87a06 Author: ting.wang Date: Sun Jan 10 00:42:39 2016 +0800 Add debug testenv in tox Once we add debug testenv, we can use "tox -e debug" to debug test cases when tox is running. Then tox will use oslotest which really debug our test cases. Only we should do is insert pdb into code.It's easy to use. ref: http://docs.openstack.org/developer/oslotest/debugging.html Closes-Bug: #1534030 Change-Id: If10634fd0a8c9b9093ccd64f5ba271cf09cfc37c ** Changed in: magnum Status: In Progress => 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/1534030 Title: Add tox debug env Status in OpenStack Dashboard (Horizon): In Progress Status in Magnum: Fix Released Status in python-magnumclient: In Progress Bug description: Once we add tox debug env in tox.ini , we can debug test cases when tox is running. In fact, we use oslotest to debug. oslotest is OpenStack Testing Framework and Utilities. When we run "tox -e debug", tox uses oslotest to debug our test cases. links: http://docs.openstack.org/developer/oslotest/index.html Usage: insert pdb;pdb.set_trace() into where you want to debug in test cases. And then run command "tox -e debug" to break the procedure. Details about how to debug, please click this link: http://docs.openstack.org/developer/oslotest/features.html It's easy to use and convient for us to debug those test cases. Meantime, I add [testenv:debug-py27]. So, we can run "tox -e debug-py27" to designate python env of running debug. Just like we run "tox -e py27". In fact, why we run "tox" instead of "run -e py27" is that we have written py27 in [tox] envlist already, so we don't need to write it again. But we don't need to write debug in env, so we can write [debug-py27]. Actually, It's not necessary, but only to be a little more robust. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1534030/+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 1535225] [NEW] Multiple gateway ports are created if multiple API requests update same router's gateway at the same time
Public bug reported: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend.I am using the latest codes. I have one external network and one router. If I run $neutron router- gateway-set at three controllers at the same time, I will end up with three ports created on the external network. Although, only the latest created port would be updated as the router's default gateway IP, the former two ports would remain in both routerports and ports database. Besides, the former two ports could not be deleted from $ neutron router-gateway-clear command. They can only be deleted from database by hand. How to reproduce: Step 1: Create an external network $ neutron net-create ext-net --router:external True Step 2: Create a subnet on the external network $ neutron subnet-create --name ext-subnet ext-net 192.168.122.0/24 Step 3: Create a router $ neutron router-create router-gateway-test Step 4: Set gateway to the router on three controllers at the same time On controller1: $ neutron router-gateway-set router-gateway-test ext-net On controller2: $ neutron router-gateway-set router-gateway-test ext-net On controller3: $ neutron router-gateway-set router-gateway-test ext-net The port list on the router after the above commands could be seen here http://paste.openstack.org/show/484091/ Step 5: Clear the gateway on the router $ neutron router-gateway-clear router-gateway-test ext-net The port list on the router after Step 5 could be seen here http://paste.openstack.org/show/484092/ As we can see, the two ports created earlier were not able to be cleared through CLI. Step 6: Try to deletes the rest two router ports $ neutron port-delete 3095887a-cb2d-46eb-bf56-be6305596868 $ neutron port-delete 76a42eda-33ce-4048-882a-6f8cb4d7137c where '3095887a-cb2d-46eb-bf56-be6305596868' and '76a42eda-33ce-4048-882a-6f8cb4d7137c' are the two remaining gateway ports on the router The result is shown here http://paste.openstack.org/show/484094/ The routerports and ports database info could be seen here http://paste.openstack.org/show/484095/ , where '9a261e95-1f3b-4c8f- 91a6-098b9fab7c25' is the id of the router we created in Step 3. ** Affects: neutron Importance: Undecided Assignee: Lujin Luo (luo-lujin) Status: New ** Changed in: neutron Assignee: (unassigned) => Lujin Luo (luo-lujin) ** Description changed: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend.I am using the latest codes. I have one external network and one router. If I run $neutron router- gateway-set at three controllers at the same time, I will end up with three ports created on the external network. Although, only the latest created port would be updated as the router's default gateway IP, the former two ports would remain in both routerports and ports database. Besides, the former two ports could not be deleted from $ neutron router-gateway-clear command. They can only be deleted from database by hand. How to reproduce: Step 1: Create an external network $ neutron net-create ext-net --router:external True Step 2: Create a subnet on the external network $ neutron subnet-create --name ext-subnet ext-net 192.168.122.0/24 Step 3: Create a router $ neutron router-create router-gateway-test Step 4: Set gateway to the router on three controllers at the same time On controller1: $ neutron router-gateway-set router-gateway-test ext-net On controller2: $ neutron router-gateway-set router-gateway-test ext-net On controller3: $ neutron router-gateway-set router-gateway-test ext-net The port list on the router after the above commands could be seen here - http://paste.openstack.org/show/483693/ + http://paste.openstack.org/show/484091/ Step 5: Clear the gateway on the router $ neutron router-gateway-clear router-gateway-test ext-net The port list on the router after Step 5 could be seen here - http://paste.openstack.org/show/483694/ + http://paste.openstack.org/show/484092/ As we can see, the two ports created earlier were not able to be cleared through CLI. + Step 6: Try to deletes the rest two router ports + $ neutron port-delete 3095887a-cb2d-46eb-bf56-be6305596868 + $ neutron port-delete 76a42eda-33ce-4048-882a-6f8cb4d7137c + where '3095887a-cb2d-46eb-bf56-be6305596868' and '76a42eda-33ce-4048-882a-6f8cb4d7137c' are the two remaining gateway ports on the router + The result is shown here http://paste.openstack.org/show/484094/ + The routerports and ports database info could be seen here - http://paste.openstack.org/show/483695/ , where '9a261e95-1f3b-4c8f- + http://paste.openstack.org/show/484095/ , where '9a261e
[Yahoo-eng-team] [Bug 1535226] [NEW] Subnets with duplicated CIDRs could be added to one router if multiple commands are executed at the same time
Public bug reported: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend.I am using the latest codes. If one router is going to add two subnets as interface, however these two subnets' CIDRs are duplicated, the expected result is the later API request would fail with error message like this Bad router request: Cidr 192.166.100.0/24 of subnet bee7663c-f0a0-4120-b556-944af7ca40cf overlaps with cidr 192.166.0.0/16 of subnet 697c82cf-82fd-4187-b460-7046c81f13dc. But when we run the two commands at the same time, both commands would work and the router would end up with two ports, which have duplicated CIDRs. I have tested for more than 20 times and in only once have I received the expected error message. How to reproduce Step 1: Create a router $ neutron router-create router-subnet-test Step 2: Create two internal networks $ neutron net-create net1 $ neutron net-create net2 Step 3: Add one subnet to each of these two networks $ neutron subnet-create --name subnet1 net1 192.166.100.0/24 $ neutron subnet-create --name subnet2 net2 192.166.0.0/16 Here, we are creating two subnets on different networks with duplicated CIDRs. Step 4: Add the two subnets as one router's interface at the same time On controller1: $ neutron router-interface-add router-subnet-test subnet1 On controller2: $ neutron router-interface-add router-subnet-test subnet2 Both commands would work and we could see that the router now has two ports, which have duplicated CIDRs http://paste.openstack.org/show/483838/ In [1], we do have a method to _check_for_dup_router_subnet, but when two API requests arrive at the same time, both checks would validate. [1] https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L590 ** Affects: neutron Importance: Undecided Assignee: Lujin Luo (luo-lujin) Status: New ** Changed in: neutron Assignee: (unassigned) => Lujin Luo (luo-lujin) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535226 Title: Subnets with duplicated CIDRs could be added to one router if multiple commands are executed at the same time Status in neutron: New Bug description: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend.I am using the latest codes. If one router is going to add two subnets as interface, however these two subnets' CIDRs are duplicated, the expected result is the later API request would fail with error message like this Bad router request: Cidr 192.166.100.0/24 of subnet bee7663c-f0a0-4120-b556-944af7ca40cf overlaps with cidr 192.166.0.0/16 of subnet 697c82cf-82fd-4187-b460-7046c81f13dc. But when we run the two commands at the same time, both commands would work and the router would end up with two ports, which have duplicated CIDRs. I have tested for more than 20 times and in only once have I received the expected error message. How to reproduce Step 1: Create a router $ neutron router-create router-subnet-test Step 2: Create two internal networks $ neutron net-create net1 $ neutron net-create net2 Step 3: Add one subnet to each of these two networks $ neutron subnet-create --name subnet1 net1 192.166.100.0/24 $ neutron subnet-create --name subnet2 net2 192.166.0.0/16 Here, we are creating two subnets on different networks with duplicated CIDRs. Step 4: Add the two subnets as one router's interface at the same time On controller1: $ neutron router-interface-add router-subnet-test subnet1 On controller2: $ neutron router-interface-add router-subnet-test subnet2 Both commands would work and we could see that the router now has two ports, which have duplicated CIDRs http://paste.openstack.org/show/483838/ In [1], we do have a method to _check_for_dup_router_subnet, but when two API requests arrive at the same time, both checks would validate. [1] https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L590 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1535226/+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 1535232] [NEW] live-migration ci failure on nfs shared storage
Public bug reported: gate-tempest-dsvm-multinode-live-migration job fails on shared storage with tempest.api.compute.admin.test_live_migration.LiveBlockMigrationTestJSON.test_live_block_migration test fails. Libvirt logs on destination node: http://xsnippet.org/361328/ libvirt version: 1.2.2-0ubuntu13.1.16 qemu version: 2.0.0+dfsg-2ubuntu1.21 ** Affects: nova Importance: Undecided Status: New ** Tags: live-migration -- 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/1535232 Title: live-migration ci failure on nfs shared storage Status in OpenStack Compute (nova): New Bug description: gate-tempest-dsvm-multinode-live-migration job fails on shared storage with tempest.api.compute.admin.test_live_migration.LiveBlockMigrationTestJSON.test_live_block_migration test fails. Libvirt logs on destination node: http://xsnippet.org/361328/ libvirt version: 1.2.2-0ubuntu13.1.16 qemu version: 2.0.0+dfsg-2ubuntu1.21 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1535232/+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 1532083] Re: neutron L3 agent shows active state when admin state was made Down on the active master controller
** Changed in: neutron Status: Incomplete => 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/1532083 Title: neutron L3 agent shows active state when admin state was made Down on the active master controller Status in neutron: Invalid Bug description: Test case steps: VRRP test case Default mode : non preempt mode 1)create a VM and attach floatingip . 2)make admin state down of the L3 agent . 3)Check for the status . current status of controller is down (padawan-ccp-c1-m2-mgmt) and it did not move back to standby state . stack@padawan-ccp-c1-m1-mgmt:~$ neutron l3-agent-list-hosting-router testrouter +--+++---+--+ | id | host | admin_state_up | alive | ha_state | +--+++---+--+ | 667aff49-e369-4a94-b404-06a43c9f64b6 | padawan-ccp-c1-m1-mgmt | True | :-) | active | | dc69a0b1-6ff4-4b95-9a6f-62e80eb1dde4 | padawan-ccp-c1-m2-mgmt | False | :-) | active | | d05a13d5-402b-4b71-8309-005ffe98066f | padawan-ccp-c1-m3-mgmt | True | :-) | standby | +--+++---+--+ stack@padawan-ccp-c1-m1-mgmt:~$ neutron agent-update dc69a0b1-6ff4-4b95-9a6f-62e80eb1dde4 --admin-state-up Updated agent: dc69a0b1-6ff4-4b95-9a6f-62e80eb1dde4 stack@padawan-ccp-c1-m1-mgmt:~$ neutron l3-agent-list-hosting-router testrouter +--+++---+--+ | id | host | admin_state_up | alive | ha_state | +--+++---+--+ | 667aff49-e369-4a94-b404-06a43c9f64b6 | padawan-ccp-c1-m1-mgmt | True | :-) | active | | dc69a0b1-6ff4-4b95-9a6f-62e80eb1dde4 | padawan-ccp-c1-m2-mgmt | True | :-) | active | | d05a13d5-402b-4b71-8309-005ffe98066f | padawan-ccp-c1-m3-mgmt | True | :-) | standby | To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1532083/+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 1522112] Re: ports duplication in the VM XML when using heat and multiple networks
Reviewed: https://review.openstack.org/252565
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=3031adb857993d8196b4c9febca51ac82cf35fd6
Submitter: Jenkins
Branch:master
commit 3031adb857993d8196b4c9febca51ac82cf35fd6
Author: David Edery
Date: Wed Dec 2 19:56:54 2015 +0100
ports & networks gather should validate existance
_gather_port_ids_and_networks assumes that the input networks variable
doesn't contain the networks in ifaces. This is a wrong assumption
ever since the introduction of the "refresh_cache-" locks to
the process in the Liberty cycle (see related bugs) and the
"Refactor network API 'get_instance_nw_info'" patchset
(https://review.openstack.org/#/c/146036/).
The fix validates that the networks stated in ifaces doen't exist in the
gotten networks list.
Duplicate networks were observed at the following closed/related bugs.
Change-Id: I8c2c9e3c89babbe5e48c5129b9854013690b38f6
Closes-Bug: #1522112
Related-Bug: #1467581
Related-Bug: #1501735
** 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/1522112
Title:
ports duplication in the VM XML when using heat and multiple networks
Status in OpenStack Compute (nova):
Fix Released
Bug description:
On latest devstack with the following (part of) local.conf:
REGION_NAME=RegionOne
Q_PLUGIN=ml2
ENABLE_TENANT_VLANS=True
ML2_VLAN_RANGES=RegionOne:2:4090
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
enable_service neutron
enable_service h-eng h-api h-api-cfn h-api-cw
After a successful stack.sh, run:
neutron quota-update --network 100 --subnet 100 --port 100
Run the following script to create networks:
#!/bin/bash
NET_NUM=20
while [ $NET_NUM -gt 0 ]; do
neutron net-create NET_${NET_NUM}
neutron subnet-create --name 10.21.${NET_NUM}.0/24 --gateway
10.21.${NET_NUM}.1 NET_${NET_NUM} 10.21.${NET_NUM}.0/24
NET_NUM=$[$NET_NUM-1]
done
Create an instance with 20 ports using the following HEAT template:
heat_template_version: 2013-05-23
description: >
HOT template that just defines a single compute instance.
Contains just base features.
resources:
ovs_port_1:
type: OS::Neutron::Port
properties:
network: NET_1
ovs_port_2:
type: OS::Neutron::Port
properties:
network: NET_2
ovs_port_3:
type: OS::Neutron::Port
properties:
network: NET_3
ovs_port_4:
type: OS::Neutron::Port
properties:
network: NET_4
ovs_port_5:
type: OS::Neutron::Port
properties:
network: NET_5
ovs_port_6:
type: OS::Neutron::Port
properties:
network: NET_6
ovs_port_7:
type: OS::Neutron::Port
properties:
network: NET_7
ovs_port_8:
type: OS::Neutron::Port
properties:
network: NET_8
ovs_port_9:
type: OS::Neutron::Port
properties:
network: NET_9
ovs_port_10:
type: OS::Neutron::Port
properties:
network: NET_10
ovs_port_11:
type: OS::Neutron::Port
properties:
network: NET_11
ovs_port_12:
type: OS::Neutron::Port
properties:
network: NET_12
ovs_port_13:
type: OS::Neutron::Port
properties:
network: NET_13
ovs_port_14:
type: OS::Neutron::Port
properties:
network: NET_14
ovs_port_15:
type: OS::Neutron::Port
properties:
network: NET_15
ovs_port_16:
type: OS::Neutron::Port
properties:
network: NET_16
ovs_port_17:
type: OS::Neutron::Port
properties:
network: NET_17
ovs_port_18:
type: OS::Neutron::Port
properties:
network: NET_18
ovs_port_19:
type: OS::Neutron::Port
properties:
network: NET_19
ovs_port_20:
type: OS::Neutron::Port
properties:
network: NET_20
ovs_instance:
type: OS::Nova::Server
properties:
image: cirros-0.3.4-x86_64-uec
flavor: m1.nano
networks:
- port: { get_resource: ovs_port_1 }
- port: { get_resource: ovs_port_2 }
- port: { get_resource: ovs_port_3 }
- port: { get_resource: ovs_port_4 }
[Yahoo-eng-team] [Bug 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests
** Also affects: python-gnocchiclient (Ubuntu) Importance: Undecided Status: New ** Changed in: python-gnocchiclient (Ubuntu) Assignee: (unassigned) => Vishal kumar mahajan (mahajan-vishal-mca) -- 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/1280522 Title: Replace assertEqual(None, *) with assertIsNone in tests Status in Anchor: Fix Released Status in bifrost: Fix Committed Status in Blazar: In Progress Status in Cinder: Fix Released Status in congress: In Progress Status in dox: New Status in Glance: Fix Released Status in glance_store: Fix Released Status in heat: Fix Released Status in heat-cfntools: Fix Released Status in Heat Translator: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in kolla-mesos: Fix Released Status in Manila: Fix Released Status in networking-cisco: Fix Released Status in OpenStack Compute (nova): Fix Released Status in ooi: In Progress Status in os-client-config: Fix Released Status in python-barbicanclient: In Progress Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-congressclient: Fix Released Status in python-cueclient: Fix Released Status in python-designateclient: Fix Released Status in python-glanceclient: Fix Released Status in python-heatclient: Fix Released Status in python-ironicclient: Fix Released Status in python-manilaclient: Fix Released Status in python-neutronclient: Fix Released Status in python-openstackclient: In Progress Status in OpenStack SDK: In Progress Status in python-swiftclient: Fix Released Status in python-troveclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in refstack: In Progress Status in Sahara: Fix Released Status in Solum: In Progress Status in Stackalytics: In Progress Status in tempest: Fix Released Status in Trove: Fix Released Status in tuskar: Fix Released Status in zaqar: Fix Released Status in python-gnocchiclient package in Ubuntu: New Bug description: Replace assertEqual(None, *) with assertIsNone in tests to have more clear messages in case of failure. To manage notifications about this bug go to: https://bugs.launchpad.net/anchor/+bug/1280522/+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 1535246] [NEW] Openstack should be OpenStack on license headers
Public bug reported: There are some occurrences of Openstack which should be OpenStack. ** 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/1535246 Title: Openstack should be OpenStack on license headers Status in neutron: New Bug description: There are some occurrences of Openstack which should be OpenStack. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1535246/+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 1535247] [NEW] rpc callback mechanism does not support upgrades
Public bug reported: Liberty introduced the RPC callback mechanism, which is mainly used by QoS so far, and planned to be reused in general as notification for neutron versioned objects, when we have those more widely implemented. The mechanism relies on updating agents with fanout notifications per object version, as versioned objects have the ability to downgrade themselves before serialization, allowing older agents to still understand such objects. We lack a mechanism to identify the running agent versions, and calculate, on realtime, the version set that we need to fanout for every resource type we push through the API to the RPC callback subscribers. A devref with the logic was merged here: https://review.openstack.org/#/c/241154/ Implementation is being developed on this topic: https://review.openstack.org/#/q/topic:rpccallback-upgrades ** Affects: neutron Importance: Medium Assignee: Miguel Angel Ajo (mangelajo) Status: In Progress ** Changed in: neutron Importance: Undecided => High ** Changed in: neutron Assignee: (unassigned) => Miguel Angel Ajo (mangelajo) ** Changed in: neutron Importance: High => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535247 Title: rpc callback mechanism does not support upgrades Status in neutron: In Progress Bug description: Liberty introduced the RPC callback mechanism, which is mainly used by QoS so far, and planned to be reused in general as notification for neutron versioned objects, when we have those more widely implemented. The mechanism relies on updating agents with fanout notifications per object version, as versioned objects have the ability to downgrade themselves before serialization, allowing older agents to still understand such objects. We lack a mechanism to identify the running agent versions, and calculate, on realtime, the version set that we need to fanout for every resource type we push through the API to the RPC callback subscribers. A devref with the logic was merged here: https://review.openstack.org/#/c/241154/ Implementation is being developed on this topic: https://review.openstack.org/#/q/topic:rpccallback-upgrades To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1535247/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests
** No longer affects: python-gnocchiclient (Ubuntu) -- 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/1280522 Title: Replace assertEqual(None, *) with assertIsNone in tests Status in Anchor: Fix Released Status in bifrost: Fix Committed Status in Blazar: In Progress Status in Cinder: Fix Released Status in congress: Fix Committed Status in dox: New Status in Glance: Fix Released Status in glance_store: Fix Released Status in heat: Fix Released Status in heat-cfntools: Fix Released Status in Heat Translator: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in kolla-mesos: Fix Released Status in Manila: Fix Released Status in networking-cisco: Fix Released Status in OpenStack Compute (nova): Fix Released Status in ooi: In Progress Status in os-client-config: Fix Released Status in python-barbicanclient: In Progress Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-congressclient: Fix Released Status in python-cueclient: Fix Released Status in python-designateclient: Fix Released Status in python-glanceclient: Fix Released Status in python-heatclient: Fix Released Status in python-ironicclient: Fix Released Status in python-manilaclient: Fix Released Status in python-neutronclient: Fix Released Status in python-openstackclient: In Progress Status in OpenStack SDK: In Progress Status in python-swiftclient: Fix Released Status in python-troveclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in refstack: In Progress Status in Sahara: Fix Released Status in Solum: In Progress Status in Stackalytics: In Progress Status in tempest: Fix Released Status in Trove: Fix Released Status in tuskar: Fix Released Status in zaqar: Fix Released Bug description: Replace assertEqual(None, *) with assertIsNone in tests to have more clear messages in case of failure. To manage notifications about this bug go to: https://bugs.launchpad.net/anchor/+bug/1280522/+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 1535254] [NEW] illustration of 'notify_on_state_change' are different from implementation
Public bug reported: I'm using liberty to get notifications from nova. And I found a problem with 'notify_on_state_change'. In the configuration doc, 'notify_on_state_change' means that "If set, send compute.instance.update notifications on instance state changes." Valid values are None, 'vm_state' and 'vm_and_task_state'. However, in current implementation, if it's set to 'vm_state', compute.instance.update notifications will be sent for all the state changes and it will be a special state change notification when the vm state changes. So as to 'vm_and_task_state'. ** Affects: nova Importance: Undecided Assignee: wuhao (wuhao) Status: New ** Changed in: nova Assignee: (unassigned) => wuhao (wuhao) -- 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/1535254 Title: illustration of 'notify_on_state_change' are different from implementation Status in OpenStack Compute (nova): New Bug description: I'm using liberty to get notifications from nova. And I found a problem with 'notify_on_state_change'. In the configuration doc, 'notify_on_state_change' means that "If set, send compute.instance.update notifications on instance state changes." Valid values are None, 'vm_state' and 'vm_and_task_state'. However, in current implementation, if it's set to 'vm_state', compute.instance.update notifications will be sent for all the state changes and it will be a special state change notification when the vm state changes. So as to 'vm_and_task_state'. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1535254/+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 1532265] Re: Clicking on flavor field on the instance list table, redirects to the home page
Source issue was fixed on https://review.openstack.org/#/c/267530/ ** Changed in: horizon Status: In Progress => 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/1532265 Title: Clicking on flavor field on the instance list table, redirects to the home page Status in OpenStack Dashboard (Horizon): Invalid Bug description: Reproduce: 1 - Launch 1 or more instances 2 - Go to project - Compute - Instances 3 - Click on the flavor 4 - ?? 5 - Be redirected to your home page On the flavor links, the href is set to "#", which Im guessing ngroute is picking up? IIRC ngroute uses # as its "anchor" for routing? Removing the href but keeping it as works. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1532265/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests
** Also affects: python-tuskarclient (Ubuntu) Importance: Undecided Status: New ** Changed in: python-tuskarclient (Ubuntu) Assignee: (unassigned) => Vishal kumar mahajan (mahajan-vishal-mca) -- 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/1280522 Title: Replace assertEqual(None, *) with assertIsNone in tests Status in Anchor: Fix Released Status in bifrost: Fix Committed Status in Blazar: In Progress Status in Cinder: Fix Released Status in congress: Fix Committed Status in dox: New Status in Glance: Fix Released Status in glance_store: Fix Released Status in heat: Fix Released Status in heat-cfntools: Fix Released Status in Heat Translator: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in kolla-mesos: Fix Released Status in Manila: Fix Released Status in networking-cisco: Fix Released Status in OpenStack Compute (nova): Fix Released Status in ooi: In Progress Status in os-client-config: Fix Released Status in python-barbicanclient: In Progress Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-congressclient: Fix Released Status in python-cueclient: Fix Released Status in python-designateclient: Fix Released Status in python-glanceclient: Fix Released Status in python-heatclient: Fix Released Status in python-ironicclient: Fix Released Status in python-manilaclient: Fix Released Status in python-neutronclient: Fix Released Status in python-openstackclient: In Progress Status in OpenStack SDK: In Progress Status in python-swiftclient: Fix Released Status in python-troveclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in refstack: In Progress Status in Sahara: Fix Released Status in Solum: In Progress Status in Stackalytics: In Progress Status in tempest: Fix Released Status in Trove: Fix Released Status in tuskar: Fix Released Status in zaqar: Fix Released Status in python-tuskarclient package in Ubuntu: New Bug description: Replace assertEqual(None, *) with assertIsNone in tests to have more clear messages in case of failure. To manage notifications about this bug go to: https://bugs.launchpad.net/anchor/+bug/1280522/+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 1268480] Re: assertTrue(isinstance()) in tests should be replace with assertIsInstance()
** No longer affects: ironic ** No longer affects: python-ironicclient -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to anvil. https://bugs.launchpad.net/bugs/1268480 Title: assertTrue(isinstance()) in tests should be replace with assertIsInstance() Status in anvil: In Progress Status in Barbican: In Progress Status in Ceilometer: Fix Released Status in Cinder: In Progress Status in CloudRoast: In Progress Status in congress: Fix Released Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in ironic-python-agent: In Progress Status in OpenStack Identity (keystone): Fix Released Status in Magnum: In Progress Status in Manila: Fix Released Status in Mistral: Fix Released Status in Monasca: Fix Released Status in Murano: Fix Released Status in networking-powervm: In Progress Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-glanceclient: Fix Released Status in python-heatclient: In Progress Status in python-keystoneclient: Fix Released Status in python-manilaclient: In Progress Status in python-novaclient: Fix Released Status in python-openstackclient: In Progress Status in OpenStack SDK: Fix Released Status in python-rackclient: In Progress Status in python-tuskarclient: In Progress Status in Rally: In Progress Status in Sahara: Fix Released Status in OpenStack Object Storage (swift): In Progress Status in tempest: In Progress Status in Trove: Fix Released Status in tuskar: In Progress Bug description: some of tests use different method of assertTrue(isinstance(A, B)) or assertEqual(type(A), B). The correct way is to use assertIsInstance(A, B) provided by testtools To manage notifications about this bug go to: https://bugs.launchpad.net/anvil/+bug/1268480/+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 1356053] Re: Doesn't properly get keystone endpoint when Keystone is configured to use templated catalog
** Also affects: fuel/8.0.x Importance: Undecided Status: New ** Changed in: fuel/8.0.x Status: New => Fix Committed ** Changed in: fuel/8.0.x Importance: Undecided => High ** Changed in: fuel/8.0.x Assignee: (unassigned) => Denis Egorenko (degorenko) ** Changed in: fuel/8.0.x Milestone: None => 8.0 ** Changed in: fuel Milestone: 8.0 => 9.0 -- 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/1356053 Title: Doesn't properly get keystone endpoint when Keystone is configured to use templated catalog Status in devstack: In Progress Status in Fuel for OpenStack: Fix Committed Status in Fuel for OpenStack 8.0.x series: Fix Committed Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Python client library for Sahara: Fix Released Status in Sahara: Fix Released Status in tempest: Fix Released Bug description: When using the keystone static catalog file to register endpoints (http://docs.openstack.org/developer/keystone/configuration.html#file-based-service-catalog-templated-catalog), an endpoint registered (correctly) as catalog.region.data_processing gets read as "data-processing" by keystone. Thus, when Sahara looks for an endpoint, it is unable to find one for data_processing. This causes a problem with the commandline interface and the dashboard. Keystone seems to be converting underscores to dashes here: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L47 modifying this line to not perform the replacement seems to work fine for me, but may have unintended consequences. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1356053/+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 1356053] Re: Doesn't properly get keystone endpoint when Keystone is configured to use templated catalog
** Changed in: devstack Status: In Progress => Invalid ** Changed in: devstack Assignee: Sergey Reshetnyak (sreshetniak) => (unassigned) -- 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/1356053 Title: Doesn't properly get keystone endpoint when Keystone is configured to use templated catalog Status in devstack: Invalid Status in Fuel for OpenStack: Fix Committed Status in Fuel for OpenStack 8.0.x series: Fix Committed Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Python client library for Sahara: Fix Released Status in Sahara: Fix Released Status in tempest: Fix Released Bug description: When using the keystone static catalog file to register endpoints (http://docs.openstack.org/developer/keystone/configuration.html#file-based-service-catalog-templated-catalog), an endpoint registered (correctly) as catalog.region.data_processing gets read as "data-processing" by keystone. Thus, when Sahara looks for an endpoint, it is unable to find one for data_processing. This causes a problem with the commandline interface and the dashboard. Keystone seems to be converting underscores to dashes here: https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L47 modifying this line to not perform the replacement seems to work fine for me, but may have unintended consequences. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1356053/+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 1530742] Re: Change LOG.warn to LOG.warning
*** This bug is a duplicate of bug 1508442 *** https://bugs.launchpad.net/bugs/1508442 Reviewed: https://review.openstack.org/263112 Committed: https://git.openstack.org/cgit/openstack/mistral/commit/?id=39a025fce45dd5d5721d6263439b70c48359d798 Submitter: Jenkins Branch:master commit 39a025fce45dd5d5721d6263439b70c48359d798 Author: zhangguoqing Date: Mon Jan 4 04:52:39 2016 + Change LOG.warn to LOG.warning Python 3 deprecated the logger.warn method, see: https://docs.python.org/3/library/logging.html#logging.warning so we prefer to use warning to avoid DeprecationWarning. Change-Id: I2c7db9f6a97b131700c3aad5d49b6a206141f34b Closes-Bug: #1530742 ** Changed in: mistral 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/1530742 Title: Change LOG.warn to LOG.warning Status in ceilometer-powervm: Fix Released Status in CloudPulse: Fix Released Status in Evoque: Fix Released Status in Gnocchi: Fix Committed Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in Kingbird: Fix Released Status in Mistral: Fix Released Status in Murano: Fix Released Status in openstack-ansible: Fix Released Status in oslo.messaging: In Progress Status in oslo.middleware: New Status in oslo.vmware: New Status in python-cloudpulseclient: Fix Released Status in python-evoqueclient: In Progress Status in python-heatclient: Fix Released Status in python-muranoclient: Fix Released Status in senlin: Fix Released Status in Stackalytics: New Status in tacker: Fix Released Status in tempest: Fix Released Bug description: Python 3 deprecated the logger.warn method, see: https://docs.python.org/3/library/logging.html#logging.warning so we prefer to use warning to avoid DeprecationWarning. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer-powervm/+bug/1530742/+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 1268439] Re: range method is not same in py3.x and py2.x
Fix released as LP bug 1530249 ** Changed in: cinder 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/1268439 Title: range method is not same in py3.x and py2.x Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Identity (keystone): Invalid Status in neutron: Fix Released Status in python-ceilometerclient: Fix Released Status in python-neutronclient: Invalid Status in python-swiftclient: Fix Released Status in OpenStack Object Storage (swift): In Progress Bug description: in py3.x,range is xrange in py2.x. in py3.x, if you want get a list,you must use: list(range(value)) I review the code, find that many codes use range for loop, if used py3.x environment, it will occure error. so we must modify this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1268439/+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 1496822] Re: v2 reports instance-uuid as an option to image create
** Also affects: glance Importance: Undecided Status: New ** Changed in: glance Status: New => Confirmed ** Changed in: glance Assignee: (unassigned) => Kairat Kushaev (kkushaev) ** Changed in: glance Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1496822 Title: v2 reports instance-uuid as an option to image create Status in Glance: Confirmed Status in python-glanceclient: In Progress Bug description: Users are confused why this command isn't working: $ glance image-create --instance-uuid d098a027-5e40-4750-aab9-0dcc7a763196 --name "via glance image-create 1" +--+--+ | Property | Value| +--+--+ | checksum | None | | container_format | None | | created_at | 2015-09-16T18:14:23Z | | disk_format | None | | id | xxx | | instance_uuid| d098a027-5e40-4750-aab9-0dcc7a763196 | | min_disk | 0| | min_ram | 0| | name | via glance image-create 1| | owner| xxx | | protected| False| | size | None | | status | queued | | tags | [] | | updated_at | 2015-09-16T18:14:23Z | | virtual_size | None | | visibility | private | +--+--+ Note 'instance_uuid d098a027-5e40-4750-aab9-0dcc7a763196' in the output. It is reported/explained in the help: $ glance help image-create usage: glance image-create [--architecture ] [--protected [True|False]] [--name ] [--instance-uuid ] [--min-disk ] [--visibility ] [--kernel-id ] [--tags [ ...]] [--os-version ] [--disk-format ] [--self ] [--os-distro ] [--id ] [--owner ] [--ramdisk-id ] [--min-ram ] [--container-format ] [--property ] [--file ] [--progress] Optional arguments: --architecture Operating system architecture as specified in http://docs.openstack.org/trunk/openstack- compute/admin/content/adding-images.html --protected [True|False] If true, image will not be deletable. --name Descriptive name for the image --instance-uuid ID of instance used to create this image. Obviously it's not supported and should be removed from the help. 'v1' behaves as expected $ glance --os-image-api-version 1 image-create --instance-uuid d098a027-5e40-4750-aab9-0dcc7a763196 --name "viaglance image-create 1" usage: glance [--version] [-d] [-v] [--get-schema] [--timeout TIMEOUT] [--no-ssl-compression] [-f] [--os-image-url OS_IMAGE_URL] [--os-image-api-version OS_IMAGE_API_VERSION] [-k] [--os-cert OS_CERT] [--cert-file OS_CERT] [--os-key OS_KEY] [--key-file OS_KEY] [--os-cacert ] [--ca-file OS_CACERT] [--os-username OS_USERNAME] [--os-user-id OS_USER_ID] [--os-user-domain-id OS_USER_DOMAIN_ID] [--os-user-domain-name OS_USER_DOMAIN_NAME] [--os-project-id OS_PROJECT_ID] [--os-project-name OS_PROJECT_NAME] [--os-project-domain-id OS_PROJECT_DOMAIN_ID] [--os-project-domain-name OS_PROJECT_DOMAIN_NAME] [--os-password OS_PASSWORD] [--os-tenant-id OS_TENANT_ID] [--os-tenant-name OS_TENANT_NAME] [--os-auth-url OS_AUTH_URL] [--os-region-name OS_REGION_NAME] [--os-auth-token OS_AUTH_TOKEN] [--os-service-type OS_SERVICE_TYPE] [--os-endpoint-type OS_ENDPOINT_TYPE] ... glance: error: unrecognized arguments: --instance-uuid d098a027-5e40-4750-aab9-0dcc7a763196 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1496822/+subscriptions -- Mailing list: https
[Yahoo-eng-team] [Bug 1527593] Re: Some unit tests breaks timeutils.utcnow() usage in next case
** 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/1527593 Title: Some unit tests breaks timeutils.utcnow() usage in next case Status in OpenStack Compute (nova): Fix Released Bug description: Especially when making new test case that gets executed after case that has made timeutils.set_time_override(), it can fail if timeutils.utcnow() works unexpectedly. To have that working in new case, one has to call timeutils.clear_time_override() before using timeutils.utcnow(). This is what happens otherwise: Traceback (most recent call last): File "nova/tests/unit/compute/test_compute_api.py", line 2995, in test_host_statuses instances) File "nova/compute/api.py", line 3386, in get_instances_host_statuses host_status = self.get_instance_host_status(instance) File "nova/compute/api.py", line 3374, in get_instance_host_status instance["services"][0]) File "nova/servicegroup/api.py", line 89, in service_is_up return self._driver.is_up(member) File "nova/servicegroup/drivers/db.py", line 79, in is_up elapsed = timeutils.delta_seconds(last_heartbeat, timeutils.utcnow()) File "/home/tojuvone/nova/.tox/py27/lib/python2.7/site-packages/oslo_utils/timeutils.py", line 297, in delta_seconds delta = after - before TypeError: can't subtract offset-naive and offset-aware datetimes Cases using timeutils.set_time_override() should also make timeutils.clear_time_override() at the end. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1527593/+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 1535285] [NEW] More log needed when dhcp agent sync_state
Public bug reported: Add more log when dhcp agent sync_state ** 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/1535285 Title: More log needed when dhcp agent sync_state Status in neutron: New Bug description: Add more log when dhcp agent sync_state To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1535285/+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 1512207] Re: Fix usage of assertions
Reviewed: https://review.openstack.org/265579 Committed: https://git.openstack.org/cgit/openstack/kuryr/commit/?id=992630a4abf7ae10a281bf7a6f767488161e4b01 Submitter: Jenkins Branch:master commit 992630a4abf7ae10a281bf7a6f767488161e4b01 Author: LiuNanke Date: Sun Jan 10 02:00:57 2016 +0800 Use assertTrue/False instead of assertEqual(T/F) The usage of assertEqual(True/False, ***) should be changed to a meaningful format of assertTrue/False(***). This patch fixes the same in keystone. Closes-Bug: #1512207 Change-Id: I800fe2c849ff089882064656c21350354b729025 ** Changed in: kuryr 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/1512207 Title: Fix usage of assertions Status in Aodh: Fix Released Status in Barbican: Fix Released Status in Blazar: In Progress Status in Cinder: Invalid Status in congress: Fix Released Status in Cue: Fix Released Status in Glance: Won't Fix Status in Group Based Policy: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in Ironic Inspector: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in kuryr: Fix Released Status in Magnum: In Progress Status in Manila: Fix Released Status in Murano: Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): In Progress Status in OpenStack Health: In Progress Status in os-brick: Fix Released Status in os-net-config: In Progress Status in os-testr: In Progress Status in oslo.cache: Fix Released Status in oslo.messaging: Fix Released Status in oslo.utils: In Progress Status in Packstack: Fix Released Status in python-barbicanclient: In Progress Status in python-ceilometerclient: Fix Released Status in python-novaclient: Fix Released Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Released Status in Rally: In Progress Status in refstack: In Progress Status in requests-mock: In Progress Status in Sahara: Fix Released Status in shaker: Fix Released Status in Solum: In Progress Status in Stackalytics: Fix Released Status in OpenStack Object Storage (swift): In Progress Status in tempest: In Progress Status in Trove: Fix Released Status in tuskar: In Progress Status in Vitrage: Fix Released Status in watcher: Fix Released Status in zaqar: Fix Released Bug description: Manila should use the specific assertion: self.assertIsTrue/False(observed) instead of the generic assertion: self.assertEqual(True/False, observed) To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1512207/+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 1496822] Re: v2 reports instance-uuid as an option to image create
Reviewed: https://review.openstack.org/268013 Committed: https://git.openstack.org/cgit/openstack/python-glanceclient/commit/?id=a8d7ded8fb4f5cf1e84c185d13c6fac1b607696c Submitter: Jenkins Branch:master commit a8d7ded8fb4f5cf1e84c185d13c6fac1b607696c Author: kairat_kushaev Date: Fri Jan 15 11:50:43 2016 +0300 Enhance description of instance-uuid option for image-create Current description of instance-uuid may confuse users because they may think that instance-uuid can serve as basis for image but it just stores instance-uuid as image-metadata. So we need to enhance the description in glanceclient. Change-Id: I55829d106c9d25374df6538b3071104ee5f215f2 Closes-Bug: #1496822 ** Changed in: python-glanceclient Status: In Progress => 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/1496822 Title: v2 reports instance-uuid as an option to image create Status in Glance: In Progress Status in python-glanceclient: Fix Released Bug description: Users are confused why this command isn't working: $ glance image-create --instance-uuid d098a027-5e40-4750-aab9-0dcc7a763196 --name "via glance image-create 1" +--+--+ | Property | Value| +--+--+ | checksum | None | | container_format | None | | created_at | 2015-09-16T18:14:23Z | | disk_format | None | | id | xxx | | instance_uuid| d098a027-5e40-4750-aab9-0dcc7a763196 | | min_disk | 0| | min_ram | 0| | name | via glance image-create 1| | owner| xxx | | protected| False| | size | None | | status | queued | | tags | [] | | updated_at | 2015-09-16T18:14:23Z | | virtual_size | None | | visibility | private | +--+--+ Note 'instance_uuid d098a027-5e40-4750-aab9-0dcc7a763196' in the output. It is reported/explained in the help: $ glance help image-create usage: glance image-create [--architecture ] [--protected [True|False]] [--name ] [--instance-uuid ] [--min-disk ] [--visibility ] [--kernel-id ] [--tags [ ...]] [--os-version ] [--disk-format ] [--self ] [--os-distro ] [--id ] [--owner ] [--ramdisk-id ] [--min-ram ] [--container-format ] [--property ] [--file ] [--progress] Optional arguments: --architecture Operating system architecture as specified in http://docs.openstack.org/trunk/openstack- compute/admin/content/adding-images.html --protected [True|False] If true, image will not be deletable. --name Descriptive name for the image --instance-uuid ID of instance used to create this image. Obviously it's not supported and should be removed from the help. 'v1' behaves as expected $ glance --os-image-api-version 1 image-create --instance-uuid d098a027-5e40-4750-aab9-0dcc7a763196 --name "viaglance image-create 1" usage: glance [--version] [-d] [-v] [--get-schema] [--timeout TIMEOUT] [--no-ssl-compression] [-f] [--os-image-url OS_IMAGE_URL] [--os-image-api-version OS_IMAGE_API_VERSION] [-k] [--os-cert OS_CERT] [--cert-file OS_CERT] [--os-key OS_KEY] [--key-file OS_KEY] [--os-cacert ] [--ca-file OS_CACERT] [--os-username OS_USERNAME] [--os-user-id OS_USER_ID] [--os-user-domain-id OS_USER_DOMAIN_ID] [--os-user-domain-name OS_USER_DOMAIN_NAME] [--os-project-id OS_PROJECT_ID] [--os-project-name OS_PROJECT_NAME] [--os-project-domain-id OS_PROJECT_DOMAIN_ID] [--os-project-domain-name OS_PROJECT_DOMAIN_NAME] [--os-password OS_PASSWORD] [--os-tenant
[Yahoo-eng-team] [Bug 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests
** Also affects: designate (Ubuntu) Importance: Undecided Status: New ** Changed in: designate (Ubuntu) Assignee: (unassigned) => Vishal kumar mahajan (mahajan-vishal-mca) -- 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/1280522 Title: Replace assertEqual(None, *) with assertIsNone in tests Status in Anchor: Fix Released Status in bifrost: Fix Committed Status in Blazar: In Progress Status in Cinder: Fix Released Status in congress: Fix Committed Status in dox: New Status in Glance: Fix Released Status in glance_store: Fix Released Status in heat: Fix Released Status in heat-cfntools: Fix Released Status in Heat Translator: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in kolla-mesos: Fix Released Status in Manila: Fix Released Status in networking-cisco: Fix Released Status in OpenStack Compute (nova): Fix Released Status in ooi: In Progress Status in os-client-config: Fix Released Status in python-barbicanclient: In Progress Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-congressclient: Fix Released Status in python-cueclient: Fix Released Status in python-designateclient: Fix Released Status in python-glanceclient: Fix Released Status in python-heatclient: Fix Released Status in python-ironicclient: Fix Released Status in python-manilaclient: Fix Released Status in python-neutronclient: Fix Released Status in python-openstackclient: In Progress Status in OpenStack SDK: In Progress Status in python-swiftclient: Fix Released Status in python-troveclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in refstack: In Progress Status in Sahara: Fix Released Status in Solum: In Progress Status in Stackalytics: In Progress Status in tempest: Fix Released Status in Trove: Fix Released Status in tuskar: Fix Released Status in zaqar: Fix Released Status in designate package in Ubuntu: New Status in python-tuskarclient package in Ubuntu: Fix Committed Bug description: Replace assertEqual(None, *) with assertIsNone in tests to have more clear messages in case of failure. To manage notifications about this bug go to: https://bugs.launchpad.net/anchor/+bug/1280522/+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 1535185] Re: timeout on v2 and ml2 jobs
** Also affects: neutron Importance: Undecided Status: New ** Tags added: fwaas ** Summary changed: - timeout on v2 and ml2 jobs + timeout on networking-midonet v2 and ml2 jobs -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535185 Title: timeout on networking-midonet v2 and ml2 jobs Status in networking-midonet: In Progress Status in neutron: In Progress Bug description: probably due to fwaas router insertion tests recently added. eg. http://logs.openstack.org/68/264868/5/check/gate-tempest-dsvm-networking-midonet-v2/2006d65/ To manage notifications about this bug go to: https://bugs.launchpad.net/networking-midonet/+bug/1535185/+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 1525809] Re: networking-midonet 2015.1.2 stable/kilo release request
2015.1.4 is on PyPI now: https://pypi.python.org/pypi/networking-midonet/2015.1.4 ** Changed in: neutron Milestone: None => mitaka-2 ** 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/1525809 Title: networking-midonet 2015.1.2 stable/kilo release request Status in networking-midonet: New Status in neutron: Fix Released Bug description: please push 2015.1.2 tag on the tip of stable/kilo. namely, commit 69c7c61e1cf9934bfdaac6774e2f02a2aa5d5472 . To manage notifications about this bug go to: https://bugs.launchpad.net/networking-midonet/+bug/1525809/+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 1535327] [NEW] neutron.common.rpc has no unit test coverage
Public bug reported: The neutron.common.rpc module has no unit test coverage. The following change was made to neutron/common/rpc.py: 68 def cleanup(): 69 global TRANSPORT, NOTIFIER 70 assert TRANSPORT is not None 71 assert NOTIFIER is not None 72 #TRANSPORT.cleanup() 73 #TRANSPORT = NOTIFIER = None No unit tests failed as a result of L72-73 being commented out, meaning no unit tests are covering some of the main functionality of this module. At a minimum, the public functions and classes should be unit tested. ** Affects: neutron Importance: Undecided Status: New ** Tags: unittest -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535327 Title: neutron.common.rpc has no unit test coverage Status in neutron: New Bug description: The neutron.common.rpc module has no unit test coverage. The following change was made to neutron/common/rpc.py: 68 def cleanup(): 69 global TRANSPORT, NOTIFIER 70 assert TRANSPORT is not None 71 assert NOTIFIER is not None 72 #TRANSPORT.cleanup() 73 #TRANSPORT = NOTIFIER = None No unit tests failed as a result of L72-73 being commented out, meaning no unit tests are covering some of the main functionality of this module. At a minimum, the public functions and classes should be unit tested. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1535327/+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 1535346] [NEW] TRACE when using nova host-migrate-live or even nova live-migration
Public bug reported: Greetings, When trying to use nova live-migration we do have this trace on the compute node logs (nova-compute.log) The Vm stays in "MIGRATING" state, the VM is still up on the originating node, and never moves. VERSION IN USE: ( KILO v1 ) root@compute2:~# dpkg -l | grep nova ii nova-common 1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-compute1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node base ii nova-compute-kvm1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node (KVM) ii nova-compute-libvirt1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node libvirt support ii python-nova 1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute Python libraries ii python-novaclient 1:2.22.0-0ubuntu1~cloud0 all client library for OpenStack Compute API CMD: nova migrate-live 6b91ffb3-bf84-48e9-b07d-99603c89055c compute4 LOGS (/var/log/nova/nova-compute.log): 2016-01-18 09:55:46.160 18571 ERROR oslo_messaging.rpc.dispatcher [req-fae37d19-0867-4796-9df3-b08be2120d15 ad8ac2392f41482e887c6b44402a641d dfcd0863f170402689d89771da0ea3ff - - -] Exception during message handling: 'module' object has no attribute 'spawn' 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher Traceback (most recent call last): 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher executor_callback)) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 186, in _dispatch 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher executor_callback) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 130, in _do_dispatch 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher result = func(ctxt, **new_args) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 6668, in live_migration 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher migrate_data=migrate_data) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/exception.py", line 88, in wrapped 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher payload) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 85, in __exit__ 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/exception.py", line 71, in wrapped 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher return f(self, context, *args, **kw) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 355, in decorated_function 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher kwargs['instance'], e, sys.exc_info()) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 85, in __exit__ 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 343, in decorated_function 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 5237, in live_migration 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher block_migration, migrate_data) 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5330, in live_migration 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher utils.spawn(self._live_migration, context, instance, dest, 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher AttributeError: 'module' object has no attribute 'spawn' 2016-01-18 09:55:46.160 18571 TRACE oslo_messaging.rpc.dispatcher CMD: nova host-evacuate-live com
[Yahoo-eng-team] [Bug 1534232] Re: Glance is still using outdated md5 for image signing
*** This bug is a duplicate of bug 1516031 *** https://bugs.launchpad.net/bugs/1516031 ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** This bug has been marked a duplicate of bug 1516031 Use of MD5 in OpenStack Glance image signature (CVE-2015-8234) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1534232 Title: Glance is still using outdated md5 for image signing Status in Glance: New Status in OpenStack Security Advisory: Won't Fix Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. -- Glance is still using md5 for image signing. MD5 is outdated and should not be used for security reason. It makes it possible for malicious users to generate malicious image with same hash values. https://specs.openstack.org/openstack/glance-specs/specs/liberty/image-signing-and-verification-support.html Glance already supports computing checksums of images when an image is uploaded, and this checksum is stored with the image. This same hash (which by default is MD5) will be used for the signature verification. In the code: https://github.com/openstack/glance/blob/2682dfe2000604bd1a77cfad5ad259f084a1359f/glance/image_cache/__init__.py line 242: def cache_tee_iter(self, image_id, image_iter, image_checksum): try: current_checksum = hashlib.md5() with self.driver.open_for_write(image_id) as cache_file: for chunk in image_iter: try: cache_file.write(chunk) finally: current_checksum.update(chunk) yield chunk cache_file.flush() To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1534232/+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 1535367] [NEW] Failure on SR-IOV . Missing 'parent_addr
Public bug reported: Mellanox CI fails on SR-IOV hardware 1. Running nova from master commit ffa07781ab47baf096854cd6c22a3e433eab3f0d 2. Full logs http://144.76.193.39/ci-artifacts/269109/1/Nova-ML2-Sriov/ 3. Reproduce: ./stack.sh neutron port-create --binding:vnic_type=direct private nova boot --flavor m1.small --image mellanox_eth --nic port-id= vm1 4. port binding fails nova fails to find appropriate host ** Affects: nova Importance: Critical Status: Confirmed ** Tags: sr-iov -- 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/1535367 Title: Failure on SR-IOV . Missing 'parent_addr Status in OpenStack Compute (nova): Confirmed Bug description: Mellanox CI fails on SR-IOV hardware 1. Running nova from master commit ffa07781ab47baf096854cd6c22a3e433eab3f0d 2. Full logs http://144.76.193.39/ci-artifacts/269109/1/Nova-ML2-Sriov/ 3. Reproduce: ./stack.sh neutron port-create --binding:vnic_type=direct private nova boot --flavor m1.small --image mellanox_eth --nic port-id= vm1 4. port binding fails nova fails to find appropriate host To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1535367/+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 1535373] [NEW] evacuation of volume backed instances fails due to Cinder being provided with connector information from the original host.
Public bug reported:
1. Exact version of Nova/OpenStack you are running:
stable/kilo but this looks possible on stable/liberty and master still.
2. Relevant log files:
nova-compute.log
2016-01-16 05:57:09.522 18842 ERROR nova.compute.manager
[req-0c36ed61-4f10-45c2-b0b5-342731fe79ba a290c48ff54d4a978474ec40401658ce
8d0f09d07ced49b8a1b7f991bfd9ba38 - - -] [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] Setting instance vm_state to ERROR
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] Traceback (most recent call last):
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 6476, in
_error_out_instance_on_exception
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] yield
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 3113, in
rebuild_instance
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] self._rebuild_default_impl(**kwargs)
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2942, in
_rebuild_default_impl
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] detach_block_devices(context, bdms)
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 3091, in
detach_block_devices
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] destroy_bdm=False)
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 4956, in
_detach_volume
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc]
self.volume_api.terminate_connection(context, volume_id, connector)
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 214, in wrapper
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] res = method(self, ctx, volume_id,
*args, **kwargs)
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/nova/volume/cinder.py", line 369, in
terminate_connection
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] connector)
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/cinderclient/v2/volumes.py", line 448, in
terminate_connection
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] {'connector': connector})
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/cinderclient/v2/volumes.py", line 375, in
_action
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] return self.api.client.post(url,
body=body)
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 118, in post
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] return self._cs_request(url, 'POST',
**kwargs)
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 112, in
_cs_request
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] return self.request(url, method,
**kwargs)
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] File
"/usr/lib/python2.7/site-packages/cinderclient/client.py", line 105, in request
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] raise exceptions.from_response(resp,
body)
2016-01-16 05:57:09.522 18842 TRACE nova.compute.manager [instance:
f7302235-20b6-4fb9-b129-aaad73a1b7dc] ClientException: The server has either
erred or is incapable of perform
[Yahoo-eng-team] [Bug 1508442] Re: LOG.warn is deprecated
Reviewed: https://review.openstack.org/268204 Committed: https://git.openstack.org/cgit/openstack/watcher/commit/?id=dfc9a3b37d69e5a87a402b3283d1c0c96b2bfffb Submitter: Jenkins Branch:master commit dfc9a3b37d69e5a87a402b3283d1c0c96b2bfffb Author: Gábor Antal Date: Fri Jan 15 16:49:32 2016 +0100 Removed use of deprecated LOG.warn method LOG.warn is deprecated. We were still used it some places. So I replaced the LOG.warn method to LOG.warning, which is not deprecated. Change-Id: I9461cec569445ad6c40db9ce2feeeba1ef0af0e3 Closes-Bug: #1508442 ** Changed in: watcher Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1508442 Title: LOG.warn is deprecated Status in anvil: In Progress Status in Aodh: In Progress Status in Astara: Fix Released Status in Barbican: In Progress Status in bilean: In Progress Status in Blazar: In Progress Status in Ceilometer: Fix Released Status in cloud-init: In Progress Status in cloudkitty: Fix Released Status in congress: In Progress Status in Designate: Fix Released Status in django-openstack-auth: Fix Released Status in django-openstack-auth-kerberos: New Status in DragonFlow: Fix Released Status in ec2-api: In Progress Status in Evoque: In Progress Status in gce-api: In Progress Status in Glance: In Progress Status in glance_store: In Progress Status in Gnocchi: In Progress Status in heat: Fix Released Status in heat-cfntools: In Progress Status in OpenStack Identity (keystone): Fix Committed Status in KloudBuster: In Progress Status in kolla: Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in Mistral: In Progress Status in networking-arista: In Progress Status in networking-calico: In Progress Status in networking-cisco: In Progress Status in networking-fujitsu: In Progress Status in networking-odl: In Progress Status in networking-ofagent: In Progress Status in networking-plumgrid: In Progress Status in networking-powervm: In Progress Status in networking-vsphere: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): In Progress Status in nova-powervm: Fix Released Status in nova-solver-scheduler: In Progress Status in octavia: In Progress Status in openstack-ansible: In Progress Status in oslo.cache: Fix Released Status in oslo.privsep: In Progress Status in Packstack: Fix Released Status in python-dracclient: In Progress Status in python-magnumclient: Fix Released Status in RACK: In Progress Status in python-watcherclient: In Progress Status in shaker: In Progress Status in Solum: In Progress Status in tempest: In Progress Status in tripleo: In Progress Status in trove-dashboard: In Progress Status in tuskar: In Progress Status in watcher: Fix Released Status in zaqar: In Progress Bug description: LOG.warn is deprecated in Python 3 [1] . But it still used in a few places, non-deprecated LOG.warning should be used instead. Note: If we are using logger from oslo.log, warn is still valid [2], but I agree we can switch to LOG.warning. [1]https://docs.python.org/3/library/logging.html#logging.warning [2]https://github.com/openstack/oslo.log/blob/master/oslo_log/log.py#L85 To manage notifications about this bug go to: https://bugs.launchpad.net/anvil/+bug/1508442/+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 1532897] Re: octal ip address disallowed during create but still works during update of setting router gw
*** This bug is a duplicate of bug 1533518 *** https://bugs.launchpad.net/bugs/1533518 ** Changed in: neutron Status: Invalid => New ** This bug has been marked a duplicate of bug 1533518 Remove 'validate' key in 'type:dict_or_nodata' type in resource attribute map -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1532897 Title: octal ip address disallowed during create but still works during update of setting router gw Status in neutron: New Bug description: environment: all-in-one devstack description: we have disallowed the usage of leading "0" in ip v4 addresses due to the confusion of them being interpreted as octal addresses in some instances. This was first reported: https://bugs.launchpad.net/neutron/+bug/1524220 and then it was patched https://review.openstack.org/255217 . I am able to bypass the fix while updating gw router ip. ex: -VirtualBox:~/devstack$ neutron router-create test-routr Created a new router: +-+--+ | Field | Value| +-+--+ | admin_state_up | True | | availability_zone_hints | | | availability_zones | | | distributed | False| | external_gateway_info | | | ha | False| | id | 7b5a90b6-9db2-4a83-b249-e320cbc049e4 | | name| test-routr | | routes | | | status | ACTIVE | | tenant_id | 20042bf593564b21b5957f0977d746fc | +-+--+ -VirtualBox:~/devstack$ neutron router-gateway-set --fixed-ip subnet_id=2a146a9d-9834-4fa1-a313-64f2ad677a97,ip_address=172.24.4.014 test-routr public Request Failed: internal server error while processing your request. < ERROR HERE IS EXPECTED -VirtualBox:~/devstack$ neutron router-gateway-set --fixed-ip subnet_id=2a146a9d-9834-4fa1-a313-64f2ad677a97,ip_address=172.24.4.17 test-routr public Set gateway for router test-routr -VirtualBox:~/devstack$ neutron router-gateway-set --fixed-ip subnet_id=2a146a9d-9834-4fa1-a313-64f2ad677a97,ip_address=172.24.4.014 test-routr public Set gateway for router test-routr <-- THIS IS THE SAME THING THAT I TRIED EARLIER AND IT FAILED BUT SINCE THERE WAS ALREADY AN IP AND I WAS SIMPLY UPDATING, IT WAS ABLE TO BYPASS VALIDATION. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1532897/+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 1535392] [NEW] l2pop should use only binding info in db and not port status for db entries.
Public bug reported: l2pop should use only binding info in db and not port status for db entries. Expected: 1) port creation - after binding, l2pop should send add_fdb_entries with new port info. 2) port deletion - after deleting port in db(and binding levels), l2pop should send remove_fdb_entries with deleted port info. 3) migration - a) after clearing the binding levels from old host, l2pop should send remove_fdb_entries with old host and port info. b) after binding to new host, l2pop should send add_fdb_entries with new host and port info. With a new change, l2pop should work for only create_port, update_port and delete_port notifications and ignore get_device_details, update_device_down and update_device_up notifications. context for bug is Kevin's comment in patchset 13 https://review.openstack.org/#/c/215467/ ** Affects: neutron Importance: Undecided Assignee: venkata anil (anil-venkata) Status: New ** Changed in: neutron Assignee: (unassigned) => venkata anil (anil-venkata) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535392 Title: l2pop should use only binding info in db and not port status for db entries. Status in neutron: New Bug description: l2pop should use only binding info in db and not port status for db entries. Expected: 1) port creation - after binding, l2pop should send add_fdb_entries with new port info. 2) port deletion - after deleting port in db(and binding levels), l2pop should send remove_fdb_entries with deleted port info. 3) migration - a) after clearing the binding levels from old host, l2pop should send remove_fdb_entries with old host and port info. b) after binding to new host, l2pop should send add_fdb_entries with new host and port info. With a new change, l2pop should work for only create_port, update_port and delete_port notifications and ignore get_device_details, update_device_down and update_device_up notifications. context for bug is Kevin's comment in patchset 13 https://review.openstack.org/#/c/215467/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1535392/+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 1512207] Re: Fix usage of assertions
Reviewed: https://review.openstack.org/264243 Committed: https://git.openstack.org/cgit/openstack/solum/commit/?id=520a7b6af0978cf8d772d54c213b4095afc8cca6 Submitter: Jenkins Branch:master commit 520a7b6af0978cf8d772d54c213b4095afc8cca6 Author: Swapnil Kulkarni (coolsvap) Date: Wed Jan 6 21:25:28 2016 +0530 Use assertTrue/False instead of assertEqual(T/F) The usage of assertEqual(True/False, ***) should be changed to a meaningful format of assertTrue/False(***). Change-Id: I555f4c94d324a292c1b8bf562c8ae74b56795803 Closes-Bug:#1512207 ** Changed in: solum 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/1512207 Title: Fix usage of assertions Status in Aodh: Fix Released Status in Barbican: Fix Released Status in Blazar: In Progress Status in Cinder: Invalid Status in congress: Fix Released Status in Cue: Fix Released Status in Glance: Won't Fix Status in Group Based Policy: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in Ironic Inspector: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in kuryr: Fix Released Status in Magnum: In Progress Status in Manila: Fix Released Status in Murano: Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): In Progress Status in OpenStack Health: In Progress Status in os-brick: Fix Released Status in os-net-config: In Progress Status in os-testr: In Progress Status in oslo.cache: Fix Released Status in oslo.messaging: Fix Released Status in oslo.utils: In Progress Status in Packstack: Fix Released Status in python-barbicanclient: In Progress Status in python-ceilometerclient: Fix Released Status in python-novaclient: Fix Released Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Released Status in Rally: In Progress Status in refstack: In Progress Status in requests-mock: In Progress Status in Sahara: Fix Released Status in shaker: Fix Released Status in Solum: Fix Released Status in Stackalytics: Fix Released Status in OpenStack Object Storage (swift): In Progress Status in tempest: In Progress Status in Trove: Fix Released Status in tuskar: In Progress Status in Vitrage: Fix Released Status in watcher: Fix Released Status in zaqar: Fix Released Bug description: Manila should use the specific assertion: self.assertIsTrue/False(observed) instead of the generic assertion: self.assertEqual(True/False, observed) To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1512207/+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 1368661] Re: Unit tests sometimes fail because of stale pyc files
Reviewed: https://review.openstack.org/255108 Committed: https://git.openstack.org/cgit/openstack/solum/commit/?id=1cbe797f6c7728b6049c7a6d8542be4e37bed905 Submitter: Jenkins Branch:master commit 1cbe797f6c7728b6049c7a6d8542be4e37bed905 Author: sonu.kumar Date: Wed Dec 9 12:41:00 2015 +0530 Delete python bytecode before every test run Change-Id: Ib9f62857ea5c7375c47f1a72a941af306501d4fe Closes-Bug: #1368661 ** Changed in: solum 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/1368661 Title: Unit tests sometimes fail because of stale pyc files Status in congress: Fix Released Status in Gnocchi: Invalid Status in Ironic: Fix Released Status in Magnum: Fix Released Status in Mistral: Fix Released Status in Monasca: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in oslo.cache: Invalid Status in oslo.concurrency: Invalid Status in oslo.log: In Progress Status in oslo.service: Fix Committed Status in python-cinderclient: Fix Released Status in python-congressclient: Fix Released Status in python-cueclient: Fix Released Status in python-glanceclient: In Progress Status in python-heatclient: Fix Committed Status in python-keystoneclient: Fix Released Status in python-magnumclient: Fix Released Status in python-mistralclient: Fix Committed Status in python-neutronclient: Fix Released Status in Python client library for Sahara: Fix Committed Status in python-solumclient: In Progress Status in python-swiftclient: Fix Released Status in python-troveclient: Fix Committed Status in Python client library for Zaqar: Fix Committed Status in Solum: Fix Released Status in OpenStack Object Storage (swift): In Progress Status in Trove: Fix Released Status in zaqar: Fix Released Bug description: Because python creates pyc files during tox runs, certain changes in the tree, like deletes of files, or switching branches, can create spurious errors. This can be suppressed by PYTHONDONTWRITEBYTECODE=1 in the tox.ini. To manage notifications about this bug go to: https://bugs.launchpad.net/congress/+bug/1368661/+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 1508442] Re: LOG.warn is deprecated
Reviewed: https://review.openstack.org/263625 Committed: https://git.openstack.org/cgit/openstack/solum/commit/?id=05ddc5622b0088a231d1130c7eb4b9e473b0c243 Submitter: Jenkins Branch:master commit 05ddc5622b0088a231d1130c7eb4b9e473b0c243 Author: Swapnil Kulkarni (coolsvap) Date: Tue Jan 5 13:45:32 2016 +0530 Replace deprecated LOG.warn with LOG.warning LOG.warn is deprecated. It still used in a few places. Updated to non-deprecated LOG.warning. Change-Id: I00d4afb7f0b3a4c0449a71d8a3795fed90e12844 Closes-Bug:#1508442 ** Changed in: solum 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/1508442 Title: LOG.warn is deprecated Status in anvil: In Progress Status in Aodh: In Progress Status in Astara: Fix Released Status in Barbican: In Progress Status in bilean: In Progress Status in Blazar: In Progress Status in Ceilometer: Fix Released Status in cloud-init: In Progress Status in cloudkitty: Fix Released Status in congress: In Progress Status in Designate: Fix Released Status in django-openstack-auth: Fix Released Status in django-openstack-auth-kerberos: New Status in DragonFlow: Fix Released Status in ec2-api: In Progress Status in Evoque: In Progress Status in gce-api: In Progress Status in Glance: In Progress Status in glance_store: In Progress Status in Gnocchi: In Progress Status in heat: Fix Released Status in heat-cfntools: In Progress Status in OpenStack Identity (keystone): Fix Committed Status in KloudBuster: In Progress Status in kolla: Fix Released Status in Magnum: Fix Released Status in Manila: Fix Released Status in Mistral: In Progress Status in networking-arista: In Progress Status in networking-calico: In Progress Status in networking-cisco: In Progress Status in networking-fujitsu: In Progress Status in networking-odl: In Progress Status in networking-ofagent: In Progress Status in networking-plumgrid: In Progress Status in networking-powervm: In Progress Status in networking-vsphere: In Progress Status in neutron: In Progress Status in OpenStack Compute (nova): In Progress Status in nova-powervm: Fix Released Status in nova-solver-scheduler: In Progress Status in octavia: In Progress Status in openstack-ansible: In Progress Status in oslo.cache: Fix Released Status in oslo.privsep: In Progress Status in Packstack: Fix Released Status in python-dracclient: In Progress Status in python-magnumclient: Fix Released Status in RACK: In Progress Status in python-watcherclient: In Progress Status in shaker: In Progress Status in Solum: Fix Released Status in tempest: In Progress Status in tripleo: In Progress Status in trove-dashboard: In Progress Status in tuskar: In Progress Status in watcher: Fix Released Status in zaqar: In Progress Bug description: LOG.warn is deprecated in Python 3 [1] . But it still used in a few places, non-deprecated LOG.warning should be used instead. Note: If we are using logger from oslo.log, warn is still valid [2], but I agree we can switch to LOG.warning. [1]https://docs.python.org/3/library/logging.html#logging.warning [2]https://github.com/openstack/oslo.log/blob/master/oslo_log/log.py#L85 To manage notifications about this bug go to: https://bugs.launchpad.net/anvil/+bug/1508442/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests
Reviewed: https://review.openstack.org/259038 Committed: https://git.openstack.org/cgit/openstack/solum/commit/?id=9d45510ddaf577427bf86a2308454b79c95b5d5c Submitter: Jenkins Branch:master commit 9d45510ddaf577427bf86a2308454b79c95b5d5c Author: Shuquan Huang Date: Thu Dec 17 22:17:58 2015 +0800 Replace assertEqual(None, *) with assertIsNone in tests Replace assertEqual(None, *) with assertIsNone in tests to have more clear messages in case of failure. Change-Id: I6059a4b58bf7eb484992fa695d435cea7325e21b Closes-bug: #1280522 ** Changed in: solum 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/1280522 Title: Replace assertEqual(None, *) with assertIsNone in tests Status in Anchor: Fix Released Status in bifrost: Fix Committed Status in Blazar: In Progress Status in Cinder: Fix Released Status in congress: Fix Committed Status in dox: New Status in Glance: Fix Released Status in glance_store: Fix Released Status in heat: Fix Released Status in heat-cfntools: Fix Released Status in Heat Translator: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in kolla-mesos: Fix Released Status in Manila: Fix Released Status in networking-cisco: Fix Released Status in OpenStack Compute (nova): Fix Released Status in ooi: In Progress Status in os-client-config: Fix Released Status in python-barbicanclient: In Progress Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-congressclient: Fix Released Status in python-cueclient: Fix Released Status in python-designateclient: Fix Released Status in python-glanceclient: Fix Released Status in python-heatclient: Fix Released Status in python-ironicclient: Fix Released Status in python-manilaclient: Fix Released Status in python-neutronclient: Fix Released Status in python-openstackclient: In Progress Status in OpenStack SDK: In Progress Status in python-swiftclient: Fix Released Status in python-troveclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in refstack: In Progress Status in Sahara: Fix Released Status in Solum: Fix Released Status in Stackalytics: In Progress Status in tempest: Fix Released Status in Trove: Fix Released Status in tuskar: Fix Released Status in zaqar: Fix Released Status in designate package in Ubuntu: New Status in python-tuskarclient package in Ubuntu: Fix Committed Bug description: Replace assertEqual(None, *) with assertIsNone in tests to have more clear messages in case of failure. To manage notifications about this bug go to: https://bugs.launchpad.net/anchor/+bug/1280522/+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 1489059] Re: "db type could not be determined" running py34
Reviewed: https://review.openstack.org/260520 Committed: https://git.openstack.org/cgit/openstack/python-solumclient/commit/?id=1780734d209b957344798235d4fd53c0f2fe4d69 Submitter: Jenkins Branch:master commit 1780734d209b957344798235d4fd53c0f2fe4d69 Author: Janonymous Date: Mon Dec 21 18:23:47 2015 +0530 Put py34 first in the env order of tox To solve the problem of "db type could not be determined" on py34 we have to run first the py34 env to, then, run py27. This patch puts py34 first on the tox.ini list of envs to avoid this problem to happen. Change-Id: Ieb28867621ba4c3679cc32bb8288342d18f753c2 Closes-bug: #1489059 ** Changed in: python-solumclient 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/1489059 Title: "db type could not be determined" running py34 Status in Aodh: Fix Released Status in Barbican: Fix Released Status in Bareon: Fix Released Status in cloudkitty: Fix Committed Status in Fuel for OpenStack: In Progress Status in Glance: Fix Committed Status in glance_store: Fix Committed Status in hacking: Fix Released Status in heat: Fix Released Status in Ironic: Fix Released Status in ironic-lib: Fix Committed Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in keystonemiddleware: Fix Released Status in kolla: Fix Released Status in Manila: Fix Released Status in Murano: Fix Committed Status in networking-midonet: Fix Released Status in networking-ofagent: New Status in neutron: Fix Released Status in python-glanceclient: Fix Released Status in python-keystoneclient: Fix Released Status in python-muranoclient: Fix Released Status in python-solumclient: Fix Released Status in python-swiftclient: In Progress Status in Rally: Fix Released Status in Sahara: Fix Released Status in OpenStack Search (Searchlight): Fix Released Status in senlin: Fix Released Status in tap-as-a-service: Fix Committed Status in tempest: Fix Released Status in zaqar: Fix Released Bug description: When running tox for the first time, the py34 execution fails with an error saying "db type could not be determined". This issue is know to be caused when the run of py27 preceeds py34 and can be solved erasing the .testrepository and running "tox -e py34" first of all. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1489059/+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 1368661] Re: Unit tests sometimes fail because of stale pyc files
Reviewed: https://review.openstack.org/255105 Committed: https://git.openstack.org/cgit/openstack/python-solumclient/commit/?id=ea917357811986c94e006d8ba92e2cd0f2c7d916 Submitter: Jenkins Branch:master commit ea917357811986c94e006d8ba92e2cd0f2c7d916 Author: sonu.kumar Date: Wed Dec 9 12:34:04 2015 +0530 Delete python bytecode before every test run Change-Id: I91dbe2a92d44d5a7b8b10eaa2b7ed5812d88fcb4 Closes-Bug: #1368661 ** Changed in: python-solumclient 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/1368661 Title: Unit tests sometimes fail because of stale pyc files Status in congress: Fix Released Status in Gnocchi: Invalid Status in Ironic: Fix Released Status in Magnum: Fix Released Status in Mistral: Fix Released Status in Monasca: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in oslo.cache: Invalid Status in oslo.concurrency: Invalid Status in oslo.log: In Progress Status in oslo.service: Fix Committed Status in python-cinderclient: Fix Released Status in python-congressclient: Fix Released Status in python-cueclient: Fix Released Status in python-glanceclient: In Progress Status in python-heatclient: Fix Committed Status in python-keystoneclient: Fix Released Status in python-magnumclient: Fix Released Status in python-mistralclient: Fix Committed Status in python-neutronclient: Fix Released Status in Python client library for Sahara: Fix Committed Status in python-solumclient: Fix Released Status in python-swiftclient: Fix Released Status in python-troveclient: Fix Committed Status in Python client library for Zaqar: Fix Committed Status in Solum: Fix Released Status in OpenStack Object Storage (swift): In Progress Status in Trove: Fix Released Status in zaqar: Fix Released Bug description: Because python creates pyc files during tox runs, certain changes in the tree, like deletes of files, or switching branches, can create spurious errors. This can be suppressed by PYTHONDONTWRITEBYTECODE=1 in the tox.ini. To manage notifications about this bug go to: https://bugs.launchpad.net/congress/+bug/1368661/+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 1535437] [NEW] Deprecate `show_multiple_locations` in favor of policy
Public bug reported: Glance currently has a flag to gate multiple locations from being sent back to the user. It also has a policy rule to prevent non-admin from receiving such locations. Having both is redundant and it's caused issues in the past. Let's get rid of the config option and rely on a more granular control using policies. This requires making the following policies admin only by default: "delete_image_location": "", "get_image_location": "", "set_image_location": "", ** Affects: glance Importance: Undecided Status: New ** Tags: spec-lite -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1535437 Title: Deprecate `show_multiple_locations` in favor of policy Status in Glance: New Bug description: Glance currently has a flag to gate multiple locations from being sent back to the user. It also has a policy rule to prevent non-admin from receiving such locations. Having both is redundant and it's caused issues in the past. Let's get rid of the config option and rely on a more granular control using policies. This requires making the following policies admin only by default: "delete_image_location": "", "get_image_location": "", "set_image_location": "", To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1535437/+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 1253482] Re: Keystone's IANA-assigned default port in linux local ephemeral port range: [Errno 98] Address already in use
** Changed in: devstack 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/1253482 Title: Keystone's IANA-assigned default port in linux local ephemeral port range: [Errno 98] Address already in use Status in devstack: Fix Released Status in OpenStack Identity (keystone): Fix Released Bug description: The linux ip port local range is 32768 to 61000 as reported by sysctl: $ sysctl -a | grep ip_local_port_range net.ipv4.ip_local_port_range = 32768 61000 Keystone's default port as assigned by IANA is 35357. It is therefore possible that keystone will fail to start because some application has a socket open on port 35357. We believe this is the case logged at http://logs.openstack.org/09/57509/2/gate/gate-tempest-devstack-vm- large-ops/1171354/logs/screen-key.txt.gz?level=TRACE. To fix this devstack should shift the ephemeral port range to 49152 to 61000 to avoid IANA port allocations and to avoid linux private port ranges. Additionally keystone should document this fact so that deployers are aware of this and know to work around the funny linux default range. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1253482/+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 1505295] Re: Tox tests failing with AttributeError
The g-r sync bot got this fixed for nova. ** Changed in: nova Status: In Progress => Fix Released ** Changed in: nova Assignee: Sean Dague (sdague) => (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/1505295 Title: Tox tests failing with AttributeError Status in Cinder: Fix Released Status in Designate: Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in openstack-ansible: Fix Released Bug description: Currently all tests run in Jenkins python27 and python34 are failing with an AttributeError, saying that "'str' has no attribute 'DEALER'", as well as an AssertionError on assert TRANSPORT is not None in cinder/rpc.py. An example of the full traceback of the failure can be found here: http://paste.openstack.org/show/476040/ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1505295/+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 1503290] Re: grenade failures on mitaka side with failure prepping block device due to RPC timeout
This isn't showing up anymore and bug 1446583 is fixed so I'm assuming it was related to that. ** Changed in: nova Status: Confirmed => Invalid -- 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/1503290 Title: grenade failures on mitaka side with failure prepping block device due to RPC timeout Status in OpenStack Compute (nova): Invalid Bug description: http://logs.openstack.org/10/230510/2/gate/gate-grenade- dsvm/e796b39/logs/new/screen-n-cpu.txt.gz?level=TRACE#_2015-10-06_05_39_36_682 2015-10-06 05:39:36.682 ERROR nova.compute.manager [req-03e13a69-3da6-4bc6-bcab-3b2a3fe4d236 tempest-ServersTestManualDisk-1771971010 tempest-ServersTestManualDisk-1239478904] [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] Build of instance 816e60bb-0085-4b0b-9a00-dbd24c339959 aborted: Failure prepping block device. 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] Traceback (most recent call last): 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] File "/opt/stack/new/nova/nova/compute/manager.py", line 1906, in _do_build_and_run_instance 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] filter_properties) 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] File "/opt/stack/new/nova/nova/compute/manager.py", line 2034, in _build_and_run_instance 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] 'create.error', fault=e) 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 195, in __exit__ 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] six.reraise(self.type_, self.value, self.tb) 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] File "/opt/stack/new/nova/nova/compute/manager.py", line 1999, in _build_and_run_instance 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] block_device_mapping) as resources: 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__ 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] return self.gen.next() 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] File "/opt/stack/new/nova/nova/compute/manager.py", line 2165, in _build_resources 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] reason=msg) 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] BuildAbortException: Build of instance 816e60bb-0085-4b0b-9a00-dbd24c339959 aborted: Failure prepping block device. 2015-10-06 05:39:36.682 5634 ERROR nova.compute.manager [instance: 816e60bb-0085-4b0b-9a00-dbd24c339959] http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiX2RvX2J1aWxkX2FuZF9ydW5faW5zdGFuY2VcIiBBTkQgbWVzc2FnZTpcImFib3J0ZWQ6IEZhaWx1cmUgcHJlcHBpbmcgYmxvY2sgZGV2aWNlXCIgQU5EIHRhZ3M6XCJzY3JlZW4tbi1jcHUudHh0XCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0NDQxMzg1OTE3NjV9 7 hits in 7 days, check and gate, all failures, master branch only. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1503290/+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 1514030] Re: /v3/policies response attribute missing
Reviewed: https://review.openstack.org/262086
Committed:
https://git.openstack.org/cgit/openstack/api-site/commit/?id=35584f1b0ffcf4900d14c7198cf09dcaa1d7a0e5
Submitter: Jenkins
Branch:master
commit 35584f1b0ffcf4900d14c7198cf09dcaa1d7a0e5
Author: Diane Fleming
Date: Mon Dec 28 18:15:48 2015 -0600
Update policy response
Change-Id: I5823ce01b21ca5d56c685913331d5ced11dcfbc3
Closes-Bug: #1514030
** Changed in: openstack-api-site
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/1514030
Title:
/v3/policies response attribute missing
Status in OpenStack Identity (keystone):
Invalid
Status in openstack-api-site:
Fix Released
Bug description:
{
"policy": {
"blob": "{\"default\": false}",
"id": "c41a4c",
"links": {
"self": "http://identity:35357/v3/policies/c41a4c";
},
"type": "application/json"
}
}
need to update
{
"policy": {
"blob": "{'foobar_user': 'role:compute-user'}",
"type": "application/json",
"user_id": "0ffd248c55b443eaac5253b4e9cbf9b5"
}
}
according to http://developer.openstack.org/api-ref-identity-v3.html
and my test
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1514030/+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 1481862] Re: test_vpnaas_extensions.VPNaaSTestJSON is broken in gate-neutron-dsvm-api on stable/kilo
*** This bug is a duplicate of bug 1483266 ***
https://bugs.launchpad.net/bugs/1483266
** This bug has been marked a duplicate of bug 1483266
q-svc fails to start in kilo due to "ImportError: No module named
neutron_vpnaas.services.vpn.service_drivers.ipsec"
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1481862
Title:
test_vpnaas_extensions.VPNaaSTestJSON is broken in gate-neutron-dsvm-
api on stable/kilo
Status in neutron:
New
Bug description:
Seeing this:
http://logs.openstack.org/71/208871/1/gate/gate-neutron-dsvm-
api/7fac5e0/console.html#_2015-08-05_15_21_16_904
2015-08-05 15:21:16.904 | 2015-08-05 15:21:09.975 | {4} setUpClass
(neutron.tests.api.test_vpnaas_extensions.VPNaaSTestJSON) [0.00s] ... FAILED
2015-08-05 15:21:16.906 | 2015-08-05 15:21:09.977 |
2015-08-05 15:21:16.907 | 2015-08-05 15:21:09.978 | Captured traceback:
2015-08-05 15:21:16.909 | 2015-08-05 15:21:09.980 | ~~~
2015-08-05 15:21:16.910 | 2015-08-05 15:21:09.981 | Traceback (most
recent call last):
2015-08-05 15:21:16.910 | 2015-08-05 15:21:09.982 | File
"neutron/tests/tempest/test.py", line 260, in setUpClass
2015-08-05 15:21:16.911 | 2015-08-05 15:21:09.984 |
cls.resource_setup()
2015-08-05 15:21:16.912 | 2015-08-05 15:21:09.985 | File
"neutron/tests/api/test_vpnaas_extensions.py", line 50, in resource_setup
2015-08-05 15:21:16.913 | 2015-08-05 15:21:09.986 | cls.router['id'])
2015-08-05 15:21:16.913 | 2015-08-05 15:21:09.988 | File
"neutron/tests/api/base.py", line 378, in create_vpnservice
2015-08-05 15:21:16.914 | 2015-08-05 15:21:09.989 |
name=data_utils.rand_name("vpnservice-"))
2015-08-05 15:21:16.915 | 2015-08-05 15:21:09.990 | File
"neutron/tests/tempest/services/network/json/network_client.py", line 140, in
_create
2015-08-05 15:21:16.916 | 2015-08-05 15:21:09.992 | resp, body =
self.post(uri, post_data)
2015-08-05 15:21:16.917 | 2015-08-05 15:21:09.994 | File
"/opt/stack/new/neutron/.tox/api/local/lib/python2.7/site-packages/tempest_lib/common/rest_client.py",
line 252, in post
2015-08-05 15:21:16.917 | 2015-08-05 15:21:09.996 | return
self.request('POST', url, extra_headers, headers, body)
2015-08-05 15:21:16.918 | 2015-08-05 15:21:09.997 | File
"/opt/stack/new/neutron/.tox/api/local/lib/python2.7/site-packages/tempest_lib/common/rest_client.py",
line 629, in request
2015-08-05 15:21:16.918 | 2015-08-05 15:21:09.999 | resp, resp_body)
2015-08-05 15:21:16.919 | 2015-08-05 15:21:10.000 | File
"/opt/stack/new/neutron/.tox/api/local/lib/python2.7/site-packages/tempest_lib/common/rest_client.py",
line 675, in _error_checker
2015-08-05 15:21:16.919 | 2015-08-05 15:21:10.001 | raise
exceptions.NotFound(resp_body)
2015-08-05 15:21:16.919 | 2015-08-05 15:21:10.002 |
tempest_lib.exceptions.NotFound: Object not found
2015-08-05 15:21:16.920 | 2015-08-05 15:21:10.004 | Details: 404 Not Found
2015-08-05 15:21:16.920 | 2015-08-05 15:21:10.005 |
2015-08-05 15:21:16.920 | 2015-08-05 15:21:10.006 | The resource could
not be found.
After this change landed today:
https://review.openstack.org/#/c/209307/
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRmlsZSBcXFwibmV1dHJvbi90ZXN0cy9hcGkvYmFzZS5weVxcXCIsIGxpbmUgMzc4LCBpbiBjcmVhdGVfdnBuc2VydmljZVwiIEFORCB0YWdzOlwiY29uc29sZVwiIEFORCBidWlsZF9uYW1lOlwiZ2F0ZS1uZXV0cm9uLWRzdm0tYXBpXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0Mzg3OTU3ODg0MjIsIm1vZGUiOiIiLCJhbmFseXplX2ZpZWxkIjoiIn0=
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1481862/+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 1489581] Re: test_create_ebs_image_and_check_boot is race failing in cells job
Marking this as fix released for nova since we just skipped the test for the cells job and agreed that it's going to be a latent bug for cells v1 that we aren't going to fix. ** Changed in: nova Status: In Progress => Fix Released ** Changed in: nova Status: Fix Released => Won't Fix -- 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/1489581 Title: test_create_ebs_image_and_check_boot is race failing in cells job Status in OpenStack Compute (nova): Won't Fix Status in tempest: Fix Released Bug description: http://logs.openstack.org/97/217197/3/check/gate-tempest-dsvm-full- ceph/cb1771f/console.html#_2015-08-27_16_17_42_279 noted here: https://review.openstack.org/#/c/213621/13/tempest/scenario/test_volume_boot_pattern.py patch: https://review.openstack.org/#/c/217804/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1489581/+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 1472692] Re: test_port_creation_and_deletion randomly fails with: eventlet.timeout.Timeout: 60 seconds
Those other bugs are fixed and this isn't showing up as an error in elastic-recheck anymore so I'm considering it fixed. ** Changed in: neutron Status: Confirmed => Fix Released ** Changed in: neutron Assignee: Rossella Sblendido (rossella-o) => (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/1472692 Title: test_port_creation_and_deletion randomly fails with: eventlet.timeout.Timeout: 60 seconds Status in neutron: Fix Released Bug description: http://logs.openstack.org/28/199128/1/gate/gate-neutron-dsvm- functional/2d48aff/console.html#_2015-07-08_08_06_35_766 2015-07-08 08:06:35.768 | 2015-07-08 08:06:35.728 | Captured traceback: 2015-07-08 08:06:35.769 | 2015-07-08 08:06:35.730 | ~~~ 2015-07-08 08:06:35.770 | 2015-07-08 08:06:35.731 | Traceback (most recent call last): 2015-07-08 08:06:35.770 | 2015-07-08 08:06:35.733 | File "neutron/tests/functional/agent/test_l2_ovs_agent.py", line 258, in test_port_creation_and_deletion 2015-07-08 08:06:35.771 | 2015-07-08 08:06:35.734 | lambda: self._expected_plugin_rpc_call( 2015-07-08 08:06:35.771 | 2015-07-08 08:06:35.736 | File "neutron/agent/linux/utils.py", line 328, in wait_until_true 2015-07-08 08:06:35.772 | 2015-07-08 08:06:35.737 | eventlet.sleep(sleep) 2015-07-08 08:06:35.772 | 2015-07-08 08:06:35.739 | File "/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/greenthread.py", line 34, in sleep 2015-07-08 08:06:35.773 | 2015-07-08 08:06:35.740 | hub.switch() 2015-07-08 08:06:35.774 | 2015-07-08 08:06:35.742 | File "/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 294, in switch 2015-07-08 08:06:35.774 | 2015-07-08 08:06:35.743 | return self.greenlet.switch() 2015-07-08 08:06:35.775 | 2015-07-08 08:06:35.745 | eventlet.timeout.Timeout: 60 seconds http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwibGFtYmRhOiBzZWxmLl9leHBlY3RlZF9wbHVnaW5fcnBjX2NhbGwoXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLW5ldXRyb24tZHN2bS1mdW5jdGlvbmFsXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MzYzNzI1MzAyOTl9 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1472692/+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 1533270] Re: Adding remote image in v2 when cache is enabled results 500 error
** Also affects: glance/liberty Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1533270 Title: Adding remote image in v2 when cache is enabled results 500 error Status in Glance: In Progress Status in Glance liberty series: New Bug description: To reproduce the issue: 1) Add an image without specifying the size 2) Enable caching 3) Get image data. This will succeed because the Content-Length is pulled from the remote store (i.e. swift). At this point, the image will be properly cached. 4) Get image data again with v2 api. This will fail with 500 error http://paste.openstack.org/show/483545/ It happens for the reason cache middleware couldn't assign value to image_meta['size'] because it expects a dictionary (as it was in v1 api), but in v2 api it's ImageTarget object. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1533270/+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 1533150] Re: Downloading empty file with enabled cache management leads to 500 error
** Also affects: glance/liberty
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1533150
Title:
Downloading empty file with enabled cache management leads to 500
error
Status in Glance:
In Progress
Status in Glance liberty series:
New
Bug description:
When I tried to download an empty image file from glance with enabled
cache management I got 500 error:
mfedosin@wdev:~$ glance --debug image-download
0af7b2e8-8e31-427b-a99f-9117f45418ef --file empty_file
curl -g -i -X GET -H 'Accept-Encoding: gzip, deflate' -H 'Accept: */*' -H
'User-Agent: python-glanceclient' -H 'Connection: keep-alive' -H 'X-Auth-Token:
{SHA1}c91066a8c438769ed454eebd759b4f8b1e488cb6' -H 'Content-Type:
application/octet-stream'
http://10.0.2.15:9292/v2/images/0af7b2e8-8e31-427b-a99f-9117f45418ef/file
Request returned failure status 500.
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/glanceclient/shell.py", line
605, in main
args.func(client, args)
File "/usr/local/lib/python2.7/dist-packages/glanceclient/v2/shell.py",
line 277, in do_image_download
body = gc.images.data(args.id)
File "/usr/local/lib/python2.7/dist-packages/glanceclient/v2/images.py",
line 194, in data
resp, body = self.http_client.get(url)
File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/http.py",
line 284, in get
return self._request('GET', url, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/http.py",
line 276, in _request
resp, body_iter = self._handle_response(resp)
File "/usr/local/lib/python2.7/dist-packages/glanceclient/common/http.py",
line 93, in _handle_response
raise exc.from_response(resp, resp.content)
HTTPInternalServerError: HTTPInternalServerError (HTTP 500)
HTTPInternalServerError (HTTP 500)
Without cache management everything works fine.
Steps to reproduce on devstack:
1. Set flavor to 'keystone+cachemanagement' in glance-api.conf (flavor =
keystone+cachemanagement)
2. Restart glance-api server
3. Create an image with empty file (file size is 0)
4. Try to download the image file from glance.
Expected result: new empty file will be created in local folder.
Actual result: HTTPInternalServerError (HTTP 500)
Logs from glance-api: http://paste.openstack.org/show/483545/
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1533150/+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 1512207] Re: Fix usage of assertions
Reviewed: https://review.openstack.org/264100 Committed: https://git.openstack.org/cgit/openstack/rally/commit/?id=09ee07d4d22e92aaf54b79cb8c5d221a7d9ae77c Submitter: Jenkins Branch:master commit 09ee07d4d22e92aaf54b79cb8c5d221a7d9ae77c Author: Yatin Kumbhare Date: Wed Jan 6 15:24:50 2016 +0530 Use assertTrue/False instead of assertEqual(T/F) The usage of assertEqual(True/False, ***) should be changed to a meaningful format of assertTrue/False(***). Change-Id: Ic07f2cbbbcabff1a5b6940f56521fda582b128a5 Closes-Bug: #1512207 ** Changed in: rally 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/1512207 Title: Fix usage of assertions Status in Aodh: Fix Released Status in Barbican: Fix Released Status in Blazar: In Progress Status in Cinder: Invalid Status in congress: Fix Released Status in Cue: Fix Released Status in Glance: Won't Fix Status in Group Based Policy: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in Ironic Inspector: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in kuryr: Fix Released Status in Magnum: In Progress Status in Manila: Fix Released Status in Murano: Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): In Progress Status in OpenStack Health: In Progress Status in os-brick: Fix Released Status in os-net-config: In Progress Status in os-testr: In Progress Status in oslo.cache: Fix Released Status in oslo.messaging: Fix Released Status in oslo.utils: In Progress Status in Packstack: Fix Released Status in python-barbicanclient: In Progress Status in python-ceilometerclient: Fix Released Status in python-novaclient: Fix Released Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Released Status in Rally: Fix Released Status in refstack: In Progress Status in requests-mock: In Progress Status in Sahara: Fix Released Status in shaker: Fix Released Status in Solum: Fix Released Status in Stackalytics: Fix Released Status in OpenStack Object Storage (swift): In Progress Status in tempest: In Progress Status in Trove: Fix Released Status in tuskar: In Progress Status in Vitrage: Fix Released Status in watcher: Fix Released Status in zaqar: Fix Released Bug description: Manila should use the specific assertion: self.assertIsTrue/False(observed) instead of the generic assertion: self.assertEqual(True/False, observed) To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1512207/+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 1535209] Re: No error raised when exec router-gateway-update with wrong attr
@Bo chi : That may be because Neutron Client is passing the value as an extra
argument.
NeutronClient has the provision to pass attributes to the neutron server, even
if the attributes are not listed for the specified CLI.
You can try to execute the above CLI with -v.
That is how the NeutronClient CLI has been defined.
For example :
On executing the following CLI
-> neutron -v router-list --Ok
I get the following request URI:
DEBUG: keystoneauth.session REQ: curl -g -i -X GET
http://10.0.2.15:9696/v2.0/routers.json?Ok=True -H "User-Agent:
python-neutronclient" -H "Accept: application/json" -H "X-Auth-Token:
{SHA1}9b464b1b710560c3c08a216337e472b24b8a724f"
Even though --Ok is not an attribute in the router-list CLI
usage: neutron router-list [-h] [-f {csv,json,table,value,yaml}] [-c COLUMN]
[--max-width ] [--noindent]
[--quote {all,minimal,none,nonnumeric}]
[--request-format {json}] [-D] [-F FIELD] [-P SIZE]
[--sort-key FIELD] [--sort-dir {asc,desc}]
In the above CLI, --fix-ip or --wrong-argument is not parsed.
For example, please find the pasted output
here.(http://paste.openstack.org/show/484220/)
You can see how the --wrong_attr is sent to the NeutronClient and it is
accepted and but not passed as that is expected behaviour from
NeutronClient for extra attributes ( beginning with --)
** 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/1535209
Title:
No error raised when exec router-gateway-update with wrong attr
Status in python-neutronclient:
New
Bug description:
Tested on Devstack environment and master version.
When running `neutron router-gateway-set` command, if the attribute is wrong,
there will be no error printed, update will success, and corresponding field is
not updated
Here the right attribute is `--fixed-ip`, but if you type `--fix-ip` or
`--wrong attribute` in `neutron router-gateway-set`, no error shows.
$ neutron router-gateway-set 1c87da7d-f0d7-42a8-964a-8c916ffbd1b4 public
--fix-ip subnet_id=7ebd8fc9-def1-47f1-97e0-e28c51dc591c,ip_address=172.24.4.8
Set gateway for router 1c87da7d-f0d7-42a8-964a-8c916ffbd1b4
bochi@stack: ~(admin)$ neutron router-list
+--+-++-+---+
| id | name| external_gateway_info
|
distributed | ha|
+--+-++-+---+
| 1c87da7d-f0d7-42a8-964a-8c916ffbd1b4 | router1 | {"network_id":
"b92781fe-2d31-49a6-b648-98d937faf0b8", "enable_snat": true,
"external_fixed_ips": [{"subnet_id": "7ebd8fc9-def1-47f1-97e0-e28c51dc591c",
"ip_address": "172.24.4.8"}]} | False | False |
Summary:
- If run `neutron router-gateway-set router net --wrong` which has a wrong
attribute, update will success
+ run `router-gateway-set` with wrong attribute should print an error
To manage notifications about this bug go to:
https://bugs.launchpad.net/python-neutronclient/+bug/1535209/+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 1535490] [NEW] gate-horizon-releasenotes job failing
Public bug reported: When trying to add new release notes, the gate-horizon-releasenotes job is failing. https://review.openstack.org/#/c/148082/ The job logs are showing it fails looking for a file that was removed. http://logs.openstack.org/82/148082/98/check/gate-horizon- releasenotes/eaf7602/console.html 2016-01-18 23:29:52.017 | reading sources... [100%] unreleased 2016-01-18 23:29:52.017 | [reno] scanning /home/jenkins/workspace/gate-horizon-releasenotes/releasenotes/notes for current branch release notes 2016-01-18 23:29:52.018 | fatal: Path 'releasenotes/notes/angularize-images-table-api-eb54206cc9ecc329.yaml' does not exist in '8ff8e8a00e108f82c3604fe79881a24484e96c4a' 2016-01-18 23:29:52.019 | 2016-01-18 23:29:52.019 | Exception occurred: 2016-01-18 23:29:52.019 | File "/home/jenkins/workspace/gate-horizon-releasenotes/.tox/releasenotes/local/lib/python2.7/site-packages/reno/formatter.py", line 37, in _indent_for_list 2016-01-18 23:29:52.020 | lines = text.splitlines() 2016-01-18 23:29:52.020 | AttributeError: 'dict' object has no attribute 'splitlines' Here's the review that removed the file in question: https://review.openstack.org/#/c/259279/ ** Affects: horizon Importance: Undecided Assignee: Brad Pokorny (bpokorny) Status: New ** Changed in: horizon Assignee: (unassigned) => Brad Pokorny (bpokorny) -- 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/1535490 Title: gate-horizon-releasenotes job failing Status in OpenStack Dashboard (Horizon): New Bug description: When trying to add new release notes, the gate-horizon-releasenotes job is failing. https://review.openstack.org/#/c/148082/ The job logs are showing it fails looking for a file that was removed. http://logs.openstack.org/82/148082/98/check/gate-horizon- releasenotes/eaf7602/console.html 2016-01-18 23:29:52.017 | reading sources... [100%] unreleased 2016-01-18 23:29:52.017 | [reno] scanning /home/jenkins/workspace/gate-horizon-releasenotes/releasenotes/notes for current branch release notes 2016-01-18 23:29:52.018 | fatal: Path 'releasenotes/notes/angularize-images-table-api-eb54206cc9ecc329.yaml' does not exist in '8ff8e8a00e108f82c3604fe79881a24484e96c4a' 2016-01-18 23:29:52.019 | 2016-01-18 23:29:52.019 | Exception occurred: 2016-01-18 23:29:52.019 | File "/home/jenkins/workspace/gate-horizon-releasenotes/.tox/releasenotes/local/lib/python2.7/site-packages/reno/formatter.py", line 37, in _indent_for_list 2016-01-18 23:29:52.020 | lines = text.splitlines() 2016-01-18 23:29:52.020 | AttributeError: 'dict' object has no attribute 'splitlines' Here's the review that removed the file in question: https://review.openstack.org/#/c/259279/ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1535490/+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 1535079] Re: ERROR nova.api.openstack.extensions BadRequest: Expecting to find username or userId in passwordCredentials
*** This bug is a duplicate of bug 1534273 *** https://bugs.launchpad.net/bugs/1534273 If you were following the RDO installation docs, the nova configuration is missing a few fields. Please see the following for the correct configuration - https://bugzilla.redhat.com/show_bug.cgi?id=1219890 This is a duplicate issue to others that have been filed and I've linked the original bug to the openstack-manuals team for them to address. Marking this as a duplicate and marking as invalid for Nova as this is a configuration issue. ** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: nova Status: New => Invalid ** Bug watch added: Red Hat Bugzilla #1219890 https://bugzilla.redhat.com/show_bug.cgi?id=1219890 ** This bug has been marked a duplicate of bug 1534273 Keystone configuration options for nova.conf missing from Redhat/CentOS install guide -- 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/1535079 Title: ERROR nova.api.openstack.extensions BadRequest: Expecting to find username or userId in passwordCredentials Status in OpenStack Compute (nova): Invalid Status in openstack-manuals: New Status in CentOS: New Bug description: Environment： centos7.1 Linux controller 3.10.0-327.4.4.el7.x86_64 I am following the installation guide from; http://docs.openstack.org/liberty/install-guide-rdo/environment.html when i tried to initiate instance using following command: nova boot --flavor m1.tiny --image cirros --nic net-id=a0bde269-d320-4853-9045-e2e90ba14031 --security-group default --key-name mykey public-instance it gives error; 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-c0467d40-2fff-42b4-915a-d5ff3f1a7ff0) tail -f nova-api.log 2016-01-17 21:33:02.244 62036 ERROR nova.api.openstack.extensions return self.request(url, 'POST', **kwargs) 2016-01-17 21:33:02.244 62036 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/keystoneclient/utils.py", line 337, in inner 2016-01-17 21:33:02.244 62036 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2016-01-17 21:33:02.244 62036 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/keystoneclient/session.py", line 401, in request 2016-01-17 21:33:02.244 62036 ERROR nova.api.openstack.extensions raise exceptions.from_response(resp, method, url) 2016-01-17 21:33:02.244 62036 ERROR nova.api.openstack.extensions BadRequest: Expecting to find username or userId in passwordCredentials - the server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID: req-64775b3f-189b-402d-81c1-c2a0ab142bbc) 2016-01-17 21:33:02.244 62036 ERROR nova.api.openstack.extensions 2016-01-17 21:33:02.245 62036 INFO nova.api.openstack.wsgi [req-c0467d40-2fff-42b4-915a-d5ff3f1a7ff0 8068f6d77937442fbf6cf5f38ef4e590 a57f6656f9b544fbb449996a6069bda2 - - -] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1535079/+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 1533867] Re: In cell mode and latest kilo code, nova get-vnc-console throw 500 error
This looks like a configuration error. Please validate your config, make sure the "compute_driver" line isn't commented out and contains the correct driver for your VM. If this is not the case or you've validated that this is indeed not a configuration option, please provide detailed steps to reproduce and information including a) your OS and version, b) the full log text of what you dived into to debug the error, and c) your nova config. ** Changed in: nova Status: New => Invalid -- 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/1533867 Title: In cell mode and latest kilo code, nova get-vnc-console throw 500 error Status in OpenStack Compute (nova): Invalid Bug description: We are using kilo version of nova (commit id b8c4f1bce356838dd3dac3b59734cf47f72373e5). Setup 3 cells with their own rabbitmq and mysql. Try nova get-vnc-console vm_id, got 500 error and error in compute side complain nova.api.openstack AttributeError: 'dict' object has no attribute 'uuid' After dive into it, the message compute received from AMQ was not been serialized to instance object but to a dict. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1533867/+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 1535514] [NEW] run_test virtual-env-path args not work
Public bug reported: when run the unit test use arg virtual-env-path, the venv path not point to the args one exec ./run_tests.sh --virtual-env-path /opt/stack the venv-path is $(pwd), not /opt/stack ** Affects: glance Importance: Undecided Assignee: Einst Crazy (yu-changcai) Status: New ** Changed in: glance Assignee: (unassigned) => Einst Crazy (yu-changcai) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1535514 Title: run_test virtual-env-path args not work Status in Glance: New Bug description: when run the unit test use arg virtual-env-path, the venv path not point to the args one exec ./run_tests.sh --virtual-env-path /opt/stack the venv-path is $(pwd), not /opt/stack To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1535514/+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 1535514] Re: run_test virtual-env-path args not work
** Also affects: neutron Importance: Undecided Status: New ** Changed in: neutron Assignee: (unassigned) => Einst Crazy (yu-changcai) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535514 Title: run_test virtual-env-path args not work Status in Glance: New Status in neutron: New Bug description: when run the unit test use arg virtual-env-path, the venv path not point to the args one exec ./run_tests.sh --virtual-env-path /opt/stack the venv-path is $(pwd), not /opt/stack To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1535514/+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 1535514] Re: run_test virtual-env-path args not work
** Also affects: manila Importance: Undecided Status: New ** Changed in: manila Assignee: (unassigned) => yapeng Yang (yang-yapeng) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535514 Title: run_test virtual-env-path args not work Status in Glance: New Status in Manila: New Status in neutron: In Progress Bug description: when run the unit test use arg virtual-env-path, the venv path not point to the args one exec ./run_tests.sh --virtual-env-path /opt/stack the venv-path is $(pwd), not /opt/stack To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1535514/+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 1476097] Re: [fwaas]Support fwaas to control east-west traffic in dvr router
[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/1476097 Title: [fwaas]Support fwaas to control east-west traffic in dvr router Status in neutron: Expired Bug description: when fwaas is enabled with dvr router, the firewall rules will only be added to snat-ROUTER_ID on controller and floating ip namespaces on compute, this will result that, only south-north traffic can be controlled by fwaas, and the east-west traffic,which produced from one subnet to another is out of fwaas' control. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1476097/+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 1286398] Re: Heat: 404 in topology tab of nested topology
[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.] ** Changed in: horizon Status: Incomplete => Expired -- 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/1286398 Title: Heat: 404 in topology tab of nested topology Status in OpenStack Dashboard (Horizon): Expired Bug description: If you launch a heat stack which contains a nested stack, click on resources, copy the Resource ID for a AWS::CloudFormation::Stack element, delete the current stack uuid out of the browser location bar, paste in the nested stack uuid, and hit enter, dashboard will show the nested stack details. This works perfectly except for the topology tab. It 404's on an ajax call to https:///project/stacks/get_d3_data// This is with RDO Havana. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1286398/+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 1465758] Re: Add the ability to create lb vip and member with network_id
[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/1465758 Title: Add the ability to create lb vip and member with network_id Status in neutron: Expired Bug description: For large deployments that use cells and provider networks, it may not make sense to only allow a user to specify the subnet in which to allocate a port because nova scheduling may not be able to allocate a port on the specified subnet. Specifying a subnet would create a conflict with that, especially when it comes to capacity management. Allowing network_id to be specified, in addition to subnet_id, will give flexibility to deployers who only want to allow allocation by network_id. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1465758/+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 1179607] Re: Present a better error message when the flavor creation fails
Reviewed: https://review.openstack.org/266460 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=b5d27265542a143da9847cf87d9e9a24229b21f5 Submitter: Jenkins Branch:master commit b5d27265542a143da9847cf87d9e9a24229b21f5 Author: Lucas Palm Date: Tue Jan 12 10:12:58 2016 -0600 Improve field validation/error handling for flavor creation Currently, if a user tries to create a new flavor or rename a flavor to a name that already exists, a field validation error will be shown that tells the user that the name is already being used by another flavor. It seems, however, that the validation does not catch the case where the user enters a flavor name that is the same string but just with uppercase/lowercase differences. Since this is not caught during the form validation, nova runs into an error later and thus throws an exception that leaves the user with a generic error message like "Unable to create flavor". To improve the form field validation and prevent the error from ever occurring in Nova, I switched the name comparisons to use the .lower() method. This was done for both Creating and Editing Flavor names. Change-Id: I44dcd98978e57282b44fdab8f134500eb9b03881 Closes-Bug: #1179607 ** Changed in: horizon Status: In Progress => 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/1179607 Title: Present a better error message when the flavor creation fails Status in OpenStack Dashboard (Horizon): Fix Released Bug description: When an error happens during the flavor creation thru the Horizon, the message "Unable to create flavor" is always presented to the user, without giving better directions on what caused the failure. Would be more useful if the message had a more meaningful text. It could be reached presenting the error message sent from the backend exception that caused the failure. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1179607/+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 1496774] Re: metadata-agent fills up log-files with " TypeError: 'NoneType' object has no attribute '__getitem__'"
** Also affects: nova Importance: Undecided Status: New ** Also affects: cinder 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/1496774 Title: metadata-agent fills up log-files with " TypeError: 'NoneType' object has no attribute '__getitem__'" Status in Cinder: New Status in neutron: Expired Status in OpenStack Compute (nova): New Status in oslo.messaging: Incomplete Bug description: Sience Monday, the log file of metadata-agent are getting full with the following error / trace: 2015-09-17 11:06:00.187 8277 ERROR oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from queue: 'NoneType' object has no attribute '__getitem__' 2015-09-17 11:06:00.187 8276 ERROR oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from queue: 'NoneType' object has no attribute '__getitem__' 2015-09-17 11:06:00.186 8267 ERROR oslo_messaging._drivers.amqpdriver [-] Failed to process incoming message, retrying... 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver Traceback (most recent call last): 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 197, in poll 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver self.conn.consume(limit=1) 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1172, in consume 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver six.next(it) 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1083, in iterconsume 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver error_callback=_error_callback) 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 870, in ensure 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver ret, channel = autoretry_method() 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver File "/usr/lib/python2.7/site-packages/kombu/connection.py", line 453, in _ensured 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver return fun(*args, **kwargs) 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver File "/usr/lib/python2.7/site-packages/kombu/connection.py", line 520, in __call__^C 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver self.revive(create_channel()) 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver File "/usr/lib/python2.7/site-packages/kombu/connection.py", line 251, in channel 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver chan = self.transport.create_channel(self.connection)^C 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver File "/usr/lib/python2.7/site-packages/kombu/transport/pyamqp.py", line 91, in create_channel 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver return connection.channel() 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver File "/usr/lib/python2.7/site-packages/amqp/connection.py", line 279, in channel 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver return self.channels[channel_id] 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver TypeError: 'NoneType' object has no attribute '__getitem__' 2015-09-17 11:06:00.186 8267 TRACE oslo_messaging._drivers.amqpdriver There was no change in the configuration before, i'm not exactly sure why it does that, the configuration looks fine and all good. I have also a 100% load on the server. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1496774/+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 1535542] [NEW] Resource that does not belong to tenant cannot be created.
Public bug reported:
Resource that does not belong to tenant cannot be created.
Creating resource that does not belong to tenant, 400 error had occurred.
According to code, tenant_id is populated before calling create_XXX methods.
Then failing with validation.
I assume that it shouldn't be blocked when the resource does not belong to
tenant.
Example of error as follows.
ubuntu@instance15:~$ curl -si -X POST -H "Content-type: application/json"
http://172.16.1.16:9696/v2.0/gw/gateway_devices/197d5dae-6e3d-4e0b-b785-56bc2219303f/remote_mac_entries
-H "X-AUTH-TOKEN:${TOKEN}" -d '{"remote_mac_entry":{"vtep_address": "2.2.2.2",
"mac_address":"aa:aa:aa:aa:aa:aa", "segmentation_id":1000}}'
HTTP/1.1 400 Bad Request
Content-Length: 110
Content-Type: application/json; charset=UTF-8
X-Openstack-Request-Id: req-0a578855-187e-4109-b762-39e8b209020e
Date: Thu, 07 Jan 2016 02:53:33 GMT
{"NeutronError": {"message": "Unrecognized attribute(s) 'tenant_id'",
"type": "HTTPBadRequest", "detail": ""}}
** 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/1535542
Title:
Resource that does not belong to tenant cannot be created.
Status in neutron:
New
Bug description:
Resource that does not belong to tenant cannot be created.
Creating resource that does not belong to tenant, 400 error had occurred.
According to code, tenant_id is populated before calling create_XXX methods.
Then failing with validation.
I assume that it shouldn't be blocked when the resource does not belong to
tenant.
Example of error as follows.
ubuntu@instance15:~$ curl -si -X POST -H "Content-type: application/json"
http://172.16.1.16:9696/v2.0/gw/gateway_devices/197d5dae-6e3d-4e0b-b785-56bc2219303f/remote_mac_entries
-H "X-AUTH-TOKEN:${TOKEN}" -d '{"remote_mac_entry":{"vtep_address": "2.2.2.2",
"mac_address":"aa:aa:aa:aa:aa:aa", "segmentation_id":1000}}'
HTTP/1.1 400 Bad Request
Content-Length: 110
Content-Type: application/json; charset=UTF-8
X-Openstack-Request-Id: req-0a578855-187e-4109-b762-39e8b209020e
Date: Thu, 07 Jan 2016 02:53:33 GMT
{"NeutronError": {"message": "Unrecognized attribute(s) 'tenant_id'",
"type": "HTTPBadRequest", "detail": ""}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1535542/+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 1535549] [NEW] Multiple ports which have duplicated CIDRs are added as one router's interfaces if commands are executed at the same time
Public bug reported: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend.I am using the latest codes. If one router is going to add two ports as its interface, however these two ports belong to two subnets which have duplicated CIDRs, the expected result would be the later API request would fail, with error message like BadRequest: Bad router request: Cidr 192.166.100.0/24 of subnet bee7663c-f0a0-4120-b556-944af7ca40cf overlaps with cidr 192.166.0.0/16 of subnet 697c82cf-82fd-4187-b460-7046c81f13dc. But if we run the two commands at the same time, both commands would succeed. The router would have two ports, which belong to subnets with duplicated CIDRs. I have tested for 30 times and only three times I could receive the expected error messages. How to reproduce: Step 1: Create a router $ neutron router-create router-port-test Step 2: Create two internal networks $ neutron net-create net1 $ neutron net-create net2 Step 3: Add one subnet to each of these two networks $ neutron subnet-create --name subnet1 net1 192.166.100.0/24 $ neutron subnet-create --name subnet2 net2 192.166.0.0/16 Here, we are creating two subnets on different networks with DUPLICATED CIDRs. Step 4: Create one port on each of these two networks $ neutron port-create --name port1 net1 $ neutron port-create --name port2 net2 Step 5: Add these two ports as the router's interface at the same time On controller1: $ neutron router-interface-add router-port-test port=port1 On controller2: $ neutron router-interface-add router-port-test port=port2 Both commands would work and we can see the ports listed on the router as http://paste.openstack.org/show/483839/ This bug is similar to [1]. We also have _check_for_dup_router_subnet method to check if subnets have duplicated CIDRs or not. The problem happens multiple API requests arrive at the same time and all the checks validate. [1] https://bugs.launchpad.net/neutron/+bug/1535226 [2] https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L535 ** Affects: neutron Importance: Undecided Assignee: Lujin Luo (luo-lujin) Status: New ** Changed in: neutron Assignee: (unassigned) => Lujin Luo (luo-lujin) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535549 Title: Multiple ports which have duplicated CIDRs are added as one router's interfaces if commands are executed at the same time Status in neutron: New Bug description: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend.I am using the latest codes. If one router is going to add two ports as its interface, however these two ports belong to two subnets which have duplicated CIDRs, the expected result would be the later API request would fail, with error message like BadRequest: Bad router request: Cidr 192.166.100.0/24 of subnet bee7663c-f0a0-4120-b556-944af7ca40cf overlaps with cidr 192.166.0.0/16 of subnet 697c82cf-82fd-4187-b460-7046c81f13dc. But if we run the two commands at the same time, both commands would succeed. The router would have two ports, which belong to subnets with duplicated CIDRs. I have tested for 30 times and only three times I could receive the expected error messages. How to reproduce: Step 1: Create a router $ neutron router-create router-port-test Step 2: Create two internal networks $ neutron net-create net1 $ neutron net-create net2 Step 3: Add one subnet to each of these two networks $ neutron subnet-create --name subnet1 net1 192.166.100.0/24 $ neutron subnet-create --name subnet2 net2 192.166.0.0/16 Here, we are creating two subnets on different networks with DUPLICATED CIDRs. Step 4: Create one port on each of these two networks $ neutron port-create --name port1 net1 $ neutron port-create --name port2 net2 Step 5: Add these two ports as the router's interface at the same time On controller1: $ neutron router-interface-add router-port-test port=port1 On controller2: $ neutron router-interface-add router-port-test port=port2 Both commands would work and we can see the ports listed on the router as http://paste.openstack.org/show/483839/ This bug is similar to [1]. We also have _check_for_dup_router_subnet method to check if subnets have duplicated CIDRs or not. The problem happens multiple API requests arrive at the same time and all the checks validate. [1] https://bugs.launchpad.net/neutron/+bug/1535226 [2] https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L535 To manage notifications about this bug go to: https://bugs.launchpad
[Yahoo-eng-team] [Bug 1535554] [NEW] Multiple dhcp agents are scheduled to host one network automatically if multiple subnets are created at the same time
Public bug reported: I have three all-in-one controller nodes deployed by DevStack with the latest codes. Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA. MariaDB Galera cluster is used as my database backend. In neutron.conf, I have made the following changes: dhcp_agents_per_network = 1 network_scheduler_driver = neutron.scheduler.dhcp_agent_scheduler.ChanceScheduler Since I only allow one dhcp agent per tenant on each controller, now I have three dhcp agents in total for a given tenant. After I created one network within this given tenant, before I add any subnets to this network, no dhcp agents would be scheduled to host this network. If I run multiple commands at the same time to add subnets to the network, we may end up with more than one dhcp agents hosting the network. It is not easy to re-produce the bug. You might need to repeat the following steps multiple times. How to reproduce: Prerequisite make the following changes in neutron.conf [DEFAULT] dhcp_agents_per_network = 1 network_scheduler_driver = neutron.scheduler.dhcp_agent_scheduler.ChanceScheduler Step 1: Confirm multiple dhcp agents are running $ neutron agent-list --agent_type='DHCP agent' my result is shown http://paste.openstack.org/show/483956/ Step 2: Create a network $ neutron net-create net-dhcptest Step 3: Create multiple subnets on the network at the same time On controller1: $ neutron subnet-create --name subnet-dhcptest-1 net-dhcptest 192.162.101.0/24 On controller2: $ neutron subnet-create --name subnet-dhcptest-2 net-dhcptest 192.162.102.0/24 Step 4: Check which dhcp agent(s) is/are hosting the network $ neutron dhcp-agent-list-hosting-net net-dhcptest my result is shown http://paste.openstack.org/show/483958/ If you end up with only one dhcp agent, please delete the subnets and network. Then repeat Step 1-4 several times. ** Affects: neutron Importance: Undecided Assignee: Lujin Luo (luo-lujin) Status: New ** Changed in: neutron Assignee: (unassigned) => Lujin Luo (luo-lujin) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535554 Title: Multiple dhcp agents are scheduled to host one network automatically if multiple subnets are created at the same time Status in neutron: New Bug description: I have three all-in-one controller nodes deployed by DevStack with the latest codes. Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA. MariaDB Galera cluster is used as my database backend. In neutron.conf, I have made the following changes: dhcp_agents_per_network = 1 network_scheduler_driver = neutron.scheduler.dhcp_agent_scheduler.ChanceScheduler Since I only allow one dhcp agent per tenant on each controller, now I have three dhcp agents in total for a given tenant. After I created one network within this given tenant, before I add any subnets to this network, no dhcp agents would be scheduled to host this network. If I run multiple commands at the same time to add subnets to the network, we may end up with more than one dhcp agents hosting the network. It is not easy to re-produce the bug. You might need to repeat the following steps multiple times. How to reproduce: Prerequisite make the following changes in neutron.conf [DEFAULT] dhcp_agents_per_network = 1 network_scheduler_driver = neutron.scheduler.dhcp_agent_scheduler.ChanceScheduler Step 1: Confirm multiple dhcp agents are running $ neutron agent-list --agent_type='DHCP agent' my result is shown http://paste.openstack.org/show/483956/ Step 2: Create a network $ neutron net-create net-dhcptest Step 3: Create multiple subnets on the network at the same time On controller1: $ neutron subnet-create --name subnet-dhcptest-1 net-dhcptest 192.162.101.0/24 On controller2: $ neutron subnet-create --name subnet-dhcptest-2 net-dhcptest 192.162.102.0/24 Step 4: Check which dhcp agent(s) is/are hosting the network $ neutron dhcp-agent-list-hosting-net net-dhcptest my result is shown http://paste.openstack.org/show/483958/ If you end up with only one dhcp agent, please delete the subnets and network. Then repeat Step 1-4 several times. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1535554/+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 1535551] [NEW] One port can be added as multiple routers' interfaces if commands are executed at the same time
Public bug reported: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend.I am using the latest codes. If one port is added as multiple routers' interfaces, the expected result is that only API request is executed successfully and the port is associated to one router. Other API requests would recieve error message like PortInUseClient: Unable to complete operation on port d2c97788-61d7-489a-8b20-7a6e8e39a217 for network 496de8cf-4284-41d7-ad6b-7dd5f232dc21. Port already has an attached device 1b316d80-f5d8-4477-88df-54b376c4c8cd. Besides, in routerports database, only one record of port is allowed to exist. However, if we run two commands to add one port as two different routers' interfaces at the same time. Both of the commands would show execution succeed. The truth is two records that the port is associated to both routers are listed in routerports database. How to reproduce Step 1: Create two routers $ neutron router-create router-1 $ neutron router-create router-2 Step 2: Create an internal network $ neutron net-create net1 Step 3: Add a subnet to the network $ neutron subnet-create --name subnet1 net1 192.166.100.0/24 Step 4: Create a port in the network $ neutron port-create --name port1 net1 Step 5: Add this port as two routers' interfaces at the same time On controller1: $ neutron router-interface-add router-1 port=port1 on controller2: $ neutron router-interface-add router-2 port=port1 Both commands would return success, as shown http://paste.openstack.org/show/483840/ Step 6: Check port list on both routers The result is shown http://paste.openstack.org/show/483843/ As we can see, only one router is successfully associated to the port Step 7: Check routerports database http://paste.openstack.org/show/483842/ where '99276755-236a-44b7-bf97-b2234d97028b' is the port_id of the port we created in Step 4. To sum up, we have two issues here a) Only one API request is executed successfully, but both commands return success b) Routerports database is updated twice and we need to delete the older record. Related source codes is [1] [1] https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L535 ** Affects: neutron Importance: Undecided Assignee: Lujin Luo (luo-lujin) Status: New ** Changed in: neutron Assignee: (unassigned) => Lujin Luo (luo-lujin) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535551 Title: One port can be added as multiple routers' interfaces if commands are executed at the same time Status in neutron: New Bug description: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend.I am using the latest codes. If one port is added as multiple routers' interfaces, the expected result is that only API request is executed successfully and the port is associated to one router. Other API requests would recieve error message like PortInUseClient: Unable to complete operation on port d2c97788-61d7-489a-8b20-7a6e8e39a217 for network 496de8cf-4284-41d7-ad6b-7dd5f232dc21. Port already has an attached device 1b316d80-f5d8-4477-88df-54b376c4c8cd. Besides, in routerports database, only one record of port is allowed to exist. However, if we run two commands to add one port as two different routers' interfaces at the same time. Both of the commands would show execution succeed. The truth is two records that the port is associated to both routers are listed in routerports database. How to reproduce Step 1: Create two routers $ neutron router-create router-1 $ neutron router-create router-2 Step 2: Create an internal network $ neutron net-create net1 Step 3: Add a subnet to the network $ neutron subnet-create --name subnet1 net1 192.166.100.0/24 Step 4: Create a port in the network $ neutron port-create --name port1 net1 Step 5: Add this port as two routers' interfaces at the same time On controller1: $ neutron router-interface-add router-1 port=port1 on controller2: $ neutron router-interface-add router-2 port=port1 Both commands would return success, as shown http://paste.openstack.org/show/483840/ Step 6: Check port list on both routers The result is shown http://paste.openstack.org/show/483843/ As we can see, only one router is successfully associated to the port Step 7: Check routerports database http://paste.openstack.org/show/483842/ where '99276755-236a-44b7-bf97-b2234d97028b' is the port_id of the port we created in Step 4. To sum up, we have two issues here a) Only one API request is executed successfully, but both com
