[Yahoo-eng-team] [Bug 1200585] Re: floatingip-create doesn't check if tenant_id exists or enabled
Fix proposed to branch: master Review: https://review.openstack.org/186264 ** Changed in: neutron Status: Invalid => In Progress ** Changed in: neutron Assignee: Jian Wen (wenjianhn) => lee jian (leejian0612) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1200585 Title: floatingip-create doesn't check if tenant_id exists or enabled Status in OpenStack Neutron (virtual network service): In Progress Bug description: how to reproduce: $ quantum floatingip-create --tenant-id 111 public Created a new floatingip: +-+--+ | Field | Value| +-+--+ | fixed_ip_address| | | floating_ip_address | 172.24.4.231 | | floating_network_id | 05fa4ce3-b834-40d1-bf9b-4794f057f40b | | id | 520b88c2-3d70-4698-aef5-620275e50cf8 | | port_id | | | router_id | | | tenant_id | 111 | +-+--+ expect result: HTTP 404 Because tenant-id doesn't exist. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1200585/+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 1459496] [NEW] task_state is not 'None' when vm stay in 'ERROR' state
Public bug reported: Compute instance task states represent what is happening to the instance at the current moment. When the instance is 'ERROR' state, the 'spawning' task_state make users confused, 'spawning' job had been done and failed, it should been set to 'None'. 1. Version of Nova $ git log -1 commit 4cf6ef68199183697a0209751575f88fe5b2a733 Merge: f40619b 70ba331 Author: Jenkins Date: Wed May 27 22:14:34 2015 + Merge "improve speed of some ec2 keypair tests" 2. Log files stack@devstack:/home/devstack/logs$ [master]$ nova list +--+---+++-++ | ID | Name | Status | Task State | Power State | Networks | +--+---+++-++ | 5fa49075-f0a0-4806-bdf3-0cedd09c7c6f | chenrui_again | ERROR | spawning | NOSTATE || | 19920850-86b0-4904-8431-bf1ed6f9cea7 | chenrui_vm| ACTIVE | - | Running | private=fd6b:c8ae:7d0d:0:f816:3eff:fe96:bbfa, 10.0.0.3 | +--+---+++-++ 2015-05-28 10:42:14.618 4705 WARNING nova.network.neutronv2.api [-] [instance: 5fa49075-f0a0-4806-bdf3-0cedd09c7c6f] Neutron error: No more fixed IPs in network: ecf5d5d3-6198-4c95-84d4-db633fb09526 2015-05-28 10:42:14.619 4705 ERROR nova.compute.manager [-] Instance failed network setup after 1 attempt(s) 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager Traceback (most recent call last): 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager File "/opt/stack/nova/nova/compute/manager.py", line 1535, in _allocate_network_async 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager dhcp_options=dhcp_options) 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager File "/opt/stack/nova/nova/network/neutronv2/api.py", line 667, in allocate_for_instance 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager self._delete_ports(neutron, instance, created_port_ids) 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 85, in __exit__ 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager six.reraise(self.type_, self.value, self.tb) 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager File "/opt/stack/nova/nova/network/neutronv2/api.py", line 659, in allocate_for_instance 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager security_group_ids, available_macs, dhcp_opts) 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager File "/opt/stack/nova/nova/network/neutronv2/api.py", line 321, in _create_port 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager raise exception.NoMoreFixedIps(net=network_id) 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager NoMoreFixedIps: No fixed IP addresses available for network: ecf5d5d3-6198-4c95-84d4-db633fb09526 2015-05-28 10:42:14.619 4705 TRACE nova.compute.manager Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/poll.py", line 115, in wait listener.cb(fileno) File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py", line 214, in main result = function(*args, **kwargs) File "/opt/stack/nova/nova/compute/manager.py", line 1552, in _allocate_network_async six.reraise(*exc_info) File "/opt/stack/nova/nova/compute/manager.py", line 1535, in _allocate_network_async dhcp_options=dhcp_options) File "/opt/stack/nova/nova/network/neutronv2/api.py", line 667, in allocate_for_instance self._delete_ports(neutron, instance, created_port_ids) File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 85, in __exit__ six.reraise(self.type_, self.value, self.tb) File "/opt/stack/nova/nova/network/neutronv2/api.py", line 659, in allocate_for_instance security_group_ids, available_macs, dhcp_opts) File "/opt/stack/nova/nova/network/neutronv2/api.py", line 321, in _create_port raise exception.NoMoreFixedIps(net=network_id) NoMoreFixedIps: No fixed IP addresses available for network: ecf5d5d3-6198-4c95-84d4-db633fb09526 Removing descriptor: 19 3. Reproduce steps: * create a neutron network and subnet, there is only 1 fixed ip in the subnet. neutron subnet-create --allocation-pool start=100.100.1.5,end=100.100.1.5 ecf5d5d3-6198-4c95-84d4-db633fb09526 100.100.1.1/24 * boot a instance with the network_id. Expected result: * booting failed, instance is 'ERROR' state and task_state is 'None' Actual result: * booting failed, instance is 'ERROR' state and task_state is 'spawning' **
[Yahoo-eng-team] [Bug 1459491] [NEW] Unexpected result when create server booted from volume
Public bug reported: Enviroment: flalvor :1 --- 1G disk. volume :128c8c78-ff3d-4636-8c5a-e27660741ec0 ,---2G,bootable,image:774b174a-a15a-492d-978d-74c3292a116e, image:774b174a-a15a-492d-978d-74c3292a116e 13M when boot from volume like this: nova boot --flavor 1 --nic net-id=2746e15a-b35a-4316-9b9a-792224f84499 --boot-volume 128c8c78-ff3d-4636-8c5a-e27660741ec0 test1 it will rasie an error: FlavorDiskTooSmall when boot from volum like this: nova boot --flavor 2 --nic net-id=2746e15a-b35a-4316-9b9a-792224f84499 --block-device id=774b174a-a15a-492d-978d-74c3292a116e,source=image,dest=volume,size=2,bootindex=0 test2 it goes well. But,the second one is same with the first one.So,either the first or the second is unexcepted. I think the second one should raise 'FlavorDiskTooSmall' error. ** Affects: nova Importance: Undecided Assignee: wangxiyuan (wangxiyuan) Status: New ** Changed in: nova Assignee: (unassigned) => wangxiyuan (wangxiyuan) ** Summary changed: - unexpect result when boot from volume + Unexpected result when create server booted from volume -- 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/1459491 Title: Unexpected result when create server booted from volume Status in OpenStack Compute (Nova): New Bug description: Enviroment: flalvor :1 --- 1G disk. volume :128c8c78-ff3d-4636-8c5a-e27660741ec0 ,---2G,bootable,image:774b174a-a15a-492d-978d-74c3292a116e, image:774b174a-a15a-492d-978d-74c3292a116e 13M when boot from volume like this: nova boot --flavor 1 --nic net-id=2746e15a-b35a-4316-9b9a-792224f84499 --boot-volume 128c8c78-ff3d-4636-8c5a-e27660741ec0 test1 it will rasie an error: FlavorDiskTooSmall when boot from volum like this: nova boot --flavor 2 --nic net-id=2746e15a-b35a-4316-9b9a-792224f84499 --block-device id=774b174a-a15a-492d-978d-74c3292a116e,source=image,dest=volume,size=2,bootindex=0 test2 it goes well. But,the second one is same with the first one.So,either the first or the second is unexcepted. I think the second one should raise 'FlavorDiskTooSmall' error. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459491/+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 1453791] Re: Lbaas Pool and Members from Different SubNets
** Package changed: neutron-lbaas (Ubuntu) => neutron ** Changed in: neutron Assignee: (unassigned) => ZongKai LI (lzklibj) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1453791 Title: Lbaas Pool and Members from Different SubNets Status in OpenStack Neutron (virtual network service): New Bug description: There is no definite mapping between Pool Subnet ID and Its Members. It is possible to Assign another Subnet with different IP for Pool and its members. For E.g A pool is created with subnet 135.254.189.0/24, and its members from Instances assigned to Another Subnet (172.21.184.0/24). Under the following reference, https://etherpad.openstack.org/p/neutron-lbaas-api-proposals For Create-Pool, Request POST /pools.json { 'pool': { 'tenant_id': 'someid', 'name': 'some name', 'subnet_id': 'id-of-subnet-where-members-reside', ---> The Subnet must be defined as per the instances Subnet 'protocol': 'HTTP', 'lb_method': 'ROUND_ROBIN' 'admin_state_up': True, } } Validation needs to be done such that the instances ( Members ) are created for the Pool of the same Subnet. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1453791/+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 1453791] [NEW] Lbaas Pool and Members from Different SubNets
You have been subscribed to a public bug: There is no definite mapping between Pool Subnet ID and Its Members. It is possible to Assign another Subnet with different IP for Pool and its members. For E.g A pool is created with subnet 135.254.189.0/24, and its members from Instances assigned to Another Subnet (172.21.184.0/24). Under the following reference, https://etherpad.openstack.org/p/neutron-lbaas-api-proposals For Create-Pool, Request POST /pools.json { 'pool': { 'tenant_id': 'someid', 'name': 'some name', 'subnet_id': 'id-of-subnet-where-members-reside', ---> The Subnet must be defined as per the instances Subnet 'protocol': 'HTTP', 'lb_method': 'ROUND_ROBIN' 'admin_state_up': True, } } Validation needs to be done such that the instances ( Members ) are created for the Pool of the same Subnet. ** Affects: neutron Importance: Undecided Assignee: ZongKai LI (lzklibj) Status: New -- Lbaas Pool and Members from Different SubNets https://bugs.launchpad.net/bugs/1453791 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. -- 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 1459483] [NEW] able to validate a Fernet token with garbage at the end
Public bug reported: I am able to verify Fernet tokens that contain garbage at the end, not so with UUID tokens. For example. UUID: curl -H "X-Auth-Token:84db9247b27d4fe6bd0a09b7b39281e2" http://localhost:35357/v2.0/tokens/84db9247b27d4fe6bd0a09b7b39281e2 Works curl -H "X-Auth-Token:84db9247b27d4fe6bd0a09b7b39281e2" http://localhost:35357/v2.0/tokens/84db9247b27d4fe6bd0a09b7b39281e2-GARBAGE {"error": {"message": "Could not find token: 84db9247b27d4fe6bd0a09b7b39281e2-GARBAGE", "code": 404, "title": "Not Found"}} Fernet on the other hand happily validates it even with garbage and even inserts -GARBAGE into the ID. curl -H "X-Auth-Token :gABVZnaEJuVPaQwW5y84w1sZt9TvxJk4Cgh8dmeISr68a7yVnl0hIpOAJ8YWluXJwym96xauaj0M737GZLzwhiF44u5JJXIjSiqQFtH3bQDrlBS- TmIAgkHcy0TsCBioof-Rzu4NbuSqkzjD5BJSRJnRqI2Sg-G-kTbRdblC5JBuyJjdMj8%3D" http://localhostt:35357/v2.0/tokens /gABVZnaEJuVPaQwW5y84w1sZt9TvxJk4Cgh8dmeISr68a7yVnl0hIpOAJ8YWluXJwym96xauaj0M737GZLzwhiF44u5JJXIjSiqQFtH3bQDrlBS- TmIAgkHcy0TsCBioof-Rzu4NbuSqkzjD5BJSRJnRqI2Sg-G-kTbRdblC5JBuyJjdMj8%3D "token": { "audit_ids": [ "WlVgiNv2RmOGaDa_4PpGGg" ], "expires": "2015-05-28T03:59:32.00Z", "id": "gABVZnaEJuVPaQwW5y84w1sZt9TvxJk4Cgh8dmeISr68a7yVnl0hIpOAJ8YWluXJwym96xauaj0M737GZLzwhiF44u5JJXIjSiqQFtH3bQDrlBS-TmIAgkHcy0TsCBioof-Rzu4NbuSqkzjD5BJSRJnRqI2Sg-G-kTbRdblC5JBuyJjdMj8=", "issued_at": "2015-05-28T01:59:32.00Z", "tenant": { "description": "Cloud Infra: Admin Tenant", "enabled": true, "id": "4764ba822ecb43e582794b875751924c", "name": "admin", "parent_id": null } }, "token": { "audit_ids": [ "WlVgiNv2RmOGaDa_4PpGGg" ], "expires": "2015-05-28T03:59:32.00Z", "id": "gABVZnaEJuVPaQwW5y84w1sZt9TvxJk4Cgh8dmeISr68a7yVnl0hIpOAJ8YWluXJwym96xauaj0M737GZLzwhiF44u5JJXIjSiqQFtH3bQDrlBS-TmIAgkHcy0TsCBioof-Rzu4NbuSqkzjD5BJSRJnRqI2Sg-G-kTbRdblC5JBuyJjdMj8=-GARBAGE", "issued_at": "2015-05-28T01:59:32.00Z", "tenant": { "description": "Cloud Infra: Admin Tenant", "enabled": true, "id": "4764ba822ecb43e582794b875751924c", "name": "admin", "parent_id": null } }, ** Affects: keystone Importance: Undecided Status: New ** Summary changed: - able to verify a Fernet token with garbage at the end + able to validate a Fernet token with garbage at the end -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1459483 Title: able to validate a Fernet token with garbage at the end Status in OpenStack Identity (Keystone): New Bug description: I am able to verify Fernet tokens that contain garbage at the end, not so with UUID tokens. For example. UUID: curl -H "X-Auth-Token:84db9247b27d4fe6bd0a09b7b39281e2" http://localhost:35357/v2.0/tokens/84db9247b27d4fe6bd0a09b7b39281e2 Works curl -H "X-Auth-Token:84db9247b27d4fe6bd0a09b7b39281e2" http://localhost:35357/v2.0/tokens/84db9247b27d4fe6bd0a09b7b39281e2-GARBAGE {"error": {"message": "Could not find token: 84db9247b27d4fe6bd0a09b7b39281e2-GARBAGE", "code": 404, "title": "Not Found"}} Fernet on the other hand happily validates it even with garbage and even inserts -GARBAGE into the ID. curl -H "X-Auth-Token :gABVZnaEJuVPaQwW5y84w1sZt9TvxJk4Cgh8dmeISr68a7yVnl0hIpOAJ8YWluXJwym96xauaj0M737GZLzwhiF44u5JJXIjSiqQFtH3bQDrlBS- TmIAgkHcy0TsCBioof- Rzu4NbuSqkzjD5BJSRJnRqI2Sg-G-kTbRdblC5JBuyJjdMj8%3D" http://localhostt:35357/v2.0/tokens /gABVZnaEJuVPaQwW5y84w1sZt9TvxJk4Cgh8dmeISr68a7yVnl0hIpOAJ8YWluXJwym96xauaj0M737GZLzwhiF44u5JJXIjSiqQFtH3bQDrlBS- TmIAgkHcy0TsCBioof-Rzu4NbuSqkzjD5BJSRJnRqI2Sg-G-kTbRdblC5JBuyJjdMj8%3D "token": { "audit_ids": [ "WlVgiNv2RmOGaDa_4PpGGg" ], "expires": "2015-05-28T03:59:32.00Z", "id": "gABVZnaEJuVPaQwW5y84w1sZt9TvxJk4Cgh8dmeISr68a7yVnl0hIpOAJ8YWluXJwym96xauaj0M737GZLzwhiF44u5JJXIjSiqQFtH3bQDrlBS-TmIAgkHcy0TsCBioof-Rzu4NbuSqkzjD5BJSRJnRqI2Sg-G-kTbRdblC5JBuyJjdMj8=", "issued_at": "2015-05-28T01:59:32.00Z", "tenant": { "description": "Cloud Infra: Admin Tenant", "enabled": true, "id": "4764ba822ecb43e582794b875751924c", "name": "admin", "parent_id": null } }, "token": { "audit_ids": [ "WlVgiNv2RmOGaDa_4PpGGg" ], "expires": "2015-05-28T03:59:32.00Z", "id": "gABVZnaEJuVPaQwW5y84w1sZt9TvxJk4Cgh8dmeISr68a7
[Yahoo-eng-team] [Bug 1459482] [NEW] Default policy too restrictive on getting user
Public bug reported: For services that need to talk to many other services, Keystone has provided the trust based authentication model. That is good. When a user (e.g. USER) raises a service request, the actual job is delegated to the service user (e.g. SERVICE). SERVICE user will use trust mechanism for authentication in calls that follow. When creating a trust between USER and SERVICE, we will need the user ID of the SERVICE user, however, it is not possible today as keystone is restricting the get_user call to be admin only. A 'service' user may need to find out his own user ID given the user name specified in the configuration file. The usage scenario is for a requester to create a trust relationship with the service user so that the service user can do jobs on the requester's behalf. Restricting user_list or user_get to only admin users is making this very cumbersome even impossible. ** Affects: keystone Importance: Undecided Assignee: Qiming Teng (tengqim) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Qiming Teng (tengqim) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1459482 Title: Default policy too restrictive on getting user Status in OpenStack Identity (Keystone): In Progress Bug description: For services that need to talk to many other services, Keystone has provided the trust based authentication model. That is good. When a user (e.g. USER) raises a service request, the actual job is delegated to the service user (e.g. SERVICE). SERVICE user will use trust mechanism for authentication in calls that follow. When creating a trust between USER and SERVICE, we will need the user ID of the SERVICE user, however, it is not possible today as keystone is restricting the get_user call to be admin only. A 'service' user may need to find out his own user ID given the user name specified in the configuration file. The usage scenario is for a requester to create a trust relationship with the service user so that the service user can do jobs on the requester's behalf. Restricting user_list or user_get to only admin users is making this very cumbersome even impossible. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1459482/+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 1459477] [NEW] gate-horizon-dsvm-integration intermittently fails with 'selenium.common.exceptions.NoSuchElementException: Message: Unable to locate element: {"method":"css selec
Public bug reported: http://logs.openstack.org/48/185848/1/gate/gate-horizon-dsvm- integration/0c6efa4/console.html#_2015-05-27_10_11_32_954 2015-05-27 10:11:32.921 | 2015-05-27 10:11:32.905 | Traceback (most recent call last): 2015-05-27 10:11:32.923 | 2015-05-27 10:11:32.906 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/tests/test_image_create_delete.py", line 29, in test_image_create_delete 2015-05-27 10:11:32.924 | 2015-05-27 10:11:32.908 | images_page.create_image(self.IMAGE_NAME) 2015-05-27 10:11:32.926 | 2015-05-27 10:11:32.909 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/pages/project/compute/imagespage.py", line 76, in create_image 2015-05-27 10:11:32.927 | 2015-05-27 10:11:32.910 | self.create_image_form.name.text = name 2015-05-27 10:11:32.930 | 2015-05-27 10:11:32.913 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/pages/project/compute/imagespage.py", line 63, in create_image_form 2015-05-27 10:11:32.931 | 2015-05-27 10:11:32.915 | self.CREATE_IMAGE_FORM_FIELDS) 2015-05-27 10:11:32.933 | 2015-05-27 10:11:32.916 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/regions/forms.py", line 242, in __init__ 2015-05-27 10:11:32.934 | 2015-05-27 10:11:32.918 | super(FormRegion, self).__init__(driver, conf, src_elem) 2015-05-27 10:11:32.936 | 2015-05-27 10:11:32.919 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/regions/forms.py", line 221, in __init__ 2015-05-27 10:11:32.938 | 2015-05-27 10:11:32.921 | src_elem = self._get_element(*self._default_form_locator) 2015-05-27 10:11:32.939 | 2015-05-27 10:11:32.923 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/regions/baseregion.py", line 101, in _get_element 2015-05-27 10:11:32.941 | 2015-05-27 10:11:32.924 | return self.src_elem.find_element(*locator) 2015-05-27 10:11:32.942 | 2015-05-27 10:11:32.925 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/webdriver.py", line 29, in find_element 2015-05-27 10:11:32.943 | 2015-05-27 10:11:32.927 | web_el = super(WrapperFindOverride, self).find_element(by, value) 2015-05-27 10:11:32.945 | 2015-05-27 10:11:32.928 | File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 664, in find_element 2015-05-27 10:11:32.947 | 2015-05-27 10:11:32.930 | {'using': by, 'value': value})['value'] 2015-05-27 10:11:32.948 | 2015-05-27 10:11:32.931 | File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/webdriver.py", line 175, in execute 2015-05-27 10:11:32.949 | 2015-05-27 10:11:32.933 | self.error_handler.check_response(response) 2015-05-27 10:11:32.951 | 2015-05-27 10:11:32.934 | File "/opt/stack/new/horizon/.tox/py27integration/local/lib/python2.7/site-packages/selenium/webdriver/remote/errorhandler.py", line 166, in check_response 2015-05-27 10:11:32.952 | 2015-05-27 10:11:32.936 | raise exception_class(message, screen, stacktrace) 2015-05-27 10:11:32.954 | 2015-05-27 10:11:32.937 | selenium.common.exceptions.NoSuchElementException: Message: Unable to locate element: {"method":"css selector","selector":"div.modal-dialog"} http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwic2VsZW5pdW0uY29tbW9uLmV4Y2VwdGlvbnMuTm9TdWNoRWxlbWVudEV4Y2VwdGlvbjogTWVzc2FnZTogVW5hYmxlIHRvIGxvY2F0ZSBlbGVtZW50OiB7XFxcIm1ldGhvZFxcXCI6XFxcImNzcyBzZWxlY3RvclxcXCIsXFxcInNlbGVjdG9yXFxcIjpcXFwiZGl2Lm1vZGFsLWRpYWxvZ1xcXCJ9XCIgQU5EIHByb2plY3Q6XCJvcGVuc3RhY2svaG9yaXpvblwiIEFORCB0YWdzOlwiY29uc29sZVwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDMyNzc2MTI5NzI3LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9 328 hits in 7 days, check and gate, master branch only. This is a different failure trace than what's in bug 1436903. ** Affects: horizon Importance: Undecided Status: Confirmed ** Changed in: horizon Status: New => Confirmed -- 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/1459477 Title: gate-horizon-dsvm-integration intermittently fails with 'selenium.common.exceptions.NoSuchElementException: Message: Unable to locate element: {"method":"css selector","selector":"div.modal- dialog"}' Status in OpenStack Dashboard (Horizon): Confirmed Bug description: http://logs.openstack.org/48/185848/1/gate/gate-horizon-dsvm- integration/0c6efa4/console.html#_2015-05-27_10_11_32_954 2015-05-27 10:11:32.921 | 2015-05-27 10:11:32.905 | Traceback (most recent call last): 2015-05-27 10:11:32.923 | 2015-05-27 10:11:32.906 | File "/opt/stack/new/horizon/openstack_dashboard/test/integration_tests/tests/test_image
[Yahoo-eng-team] [Bug 1459467] [NEW] port update multiple fixed IPs anticipating allocation fails with mac address error
Public bug reported: A port update with multiple fixed IP specifications, one with a subnet ID and one with a fixed IP that conflicts with the address picked by the one specifying the subnet ID will result in a dbduplicate entry which is presented to the user as a mac address error. ~$ neutron port-update 7521786b-6c7f-4385-b5e1-fb9565552696 --fixed-ips type=dict {subnet_id=ca9dd2f0-cbaf-4997-9f59-dee9a39f6a7d,ip_address=42.42.42.42} Unable to complete operation for network 0897a051-bf56-43c1-9083-3ac38ffef84e. The mac address None is in use. ** Affects: neutron Importance: Undecided Assignee: Kevin Benton (kevinbenton) Status: New ** Changed in: neutron Assignee: (unassigned) => Kevin Benton (kevinbenton) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1459467 Title: port update multiple fixed IPs anticipating allocation fails with mac address error Status in OpenStack Neutron (virtual network service): New Bug description: A port update with multiple fixed IP specifications, one with a subnet ID and one with a fixed IP that conflicts with the address picked by the one specifying the subnet ID will result in a dbduplicate entry which is presented to the user as a mac address error. ~$ neutron port-update 7521786b-6c7f-4385-b5e1-fb9565552696 --fixed-ips type=dict {subnet_id=ca9dd2f0-cbaf-4997-9f59-dee9a39f6a7d,ip_address=42.42.42.42} Unable to complete operation for network 0897a051-bf56-43c1-9083-3ac38ffef84e. The mac address None is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1459467/+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 1459468] [NEW] When doing resize action, CONF.allow_resize_on_same_host should check only once
Public bug reported: In the current implementation, when doing instance resize action. The CONF.allow_resize_to_same_host is first checked in compute/api which is on controller node. If CONF.allow_resize_to_same_host = True, nothing will added to filter_properties['ignore_hosts'], if it is set to False, the source host will be added to filter_properties['ignore_hosts'] and it will be ignored when performing select_destinations. The value of CONF.allow_resize_to_same_host has been checked again in compute/manager.py which is on the destination host which has already been selected by scheduler. This will lead to a problem, if CONF.allow_resize_to_same_host parameter is set to True in controller node but set to False or didn't set in compute node. When scheduler decided that the original compute node is the best one for resize but when the compute node implementing the resize action, it will throw an exception. The value of CONF.allow_resize_to_same_host should only check once in controller node (compute/api.py) and let scheduler judge which host is best for rebuild, the compute node should only perform the action when it has been selected. ** Affects: nova Importance: Undecided Assignee: Zhenyu Zheng (zhengzhenyu) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1459468 Title: When doing resize action, CONF.allow_resize_on_same_host should check only once Status in OpenStack Compute (Nova): New Bug description: In the current implementation, when doing instance resize action. The CONF.allow_resize_to_same_host is first checked in compute/api which is on controller node. If CONF.allow_resize_to_same_host = True, nothing will added to filter_properties['ignore_hosts'], if it is set to False, the source host will be added to filter_properties['ignore_hosts'] and it will be ignored when performing select_destinations. The value of CONF.allow_resize_to_same_host has been checked again in compute/manager.py which is on the destination host which has already been selected by scheduler. This will lead to a problem, if CONF.allow_resize_to_same_host parameter is set to True in controller node but set to False or didn't set in compute node. When scheduler decided that the original compute node is the best one for resize but when the compute node implementing the resize action, it will throw an exception. The value of CONF.allow_resize_to_same_host should only check once in controller node (compute/api.py) and let scheduler judge which host is best for rebuild, the compute node should only perform the action when it has been selected. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459468/+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 1341096] Re: neutron port-update allocates double fixed ip
In case someone stumbles across this like I did. What's happening in the first case is that the client parsing is getting confused and turns that into a list of two port updates, one specifying a subnet_id and one specifying an ip_address. The latter ends up giving you the IP you wanted and the first one allocates a random IP from the subnet. There is no way to just add an IP with the CLI without specifying the old addresses. We don't have a concept of a patch list in the API as far as I can tell. This seems to be a bug in the way the neutron client breaks down the first case into a list of two things. For example, the following works to set three IP addresses: neutron port-update 7521786b-6c7f-4385-b5e1-fb9565552696 --fixed-ips type=dict {ip_address=42.42.42.93,ip_address=42.42.42.92,ip_address=42.42.42.91} ** Changed in: neutron Status: Incomplete => Confirmed ** 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/1341096 Title: neutron port-update allocates double fixed ip Status in Python client library for Neutron: Confirmed Bug description: 1.create a new port 707BE8C6:/home # neutron port-create 23d588e1-3861-4f6f-89ed-2b177e7b8b36 --name why_port Created a new port: +---+--+ | Field | Value | +---+--+ | admin_state_up| True | | allowed_address_pairs | | | binding:capabilities | {"port_filter": false} | | binding:host_id | | | binding:profile | {} | | binding:vif_details | {} | | binding:vif_type | unbound | | binding:vnic_type | normal | | device_id | | | device_owner | | | fixed_ips | {"subnet_id": "7f5ae8f6-3882-4e58-bea7-1d76c5fa1bc1", "ip_address": "200.1.1.7"} | | id| d91892d0-43cf-4929-ba58-92da2a723e62 | | mac_address | fa:16:3e:0e:ac:b6 | | mac_range_id | | | name | why_port | | network_id| 23d588e1-3861-4f6f-89ed-2b177e7b8b36 | | status| DOWN | | tenant_id | 4015230803414ea3b183d4f3a4e57a57 | +---+--+ 2.update the port 707BE8C6:/home # neutron port-update d91892d0-43cf-4929-ba58-92da2a723e62 --fixed-ips type=dict {subnet_id=7f5ae8f6-3882-4e58-bea7-1d76c5fa1bc1,ip_address=200.1.1.5} Updated port: d91892d0-43cf-4929-ba58-92da2a723e62 3. show the port 707BE8C6:/home # neutron port-show d91892d0-43cf-4929-ba58-92da2a723e62 +---+--+ | Field | Value | +---+--+ | admin_state_up| True | | allowed_address_pairs | | | binding:capabilities | {"port_filter": false} | | binding:host_id | | | binding:profile | {}
[Yahoo-eng-team] [Bug 1297871] Re: Use GB instead of MB for the swap part size in Ironic
Quoting from IRC: "devananda | mrda: that feels like a discussion on the color of the trim of the bikeshed we already store farm equipment in" ** Changed in: ironic Status: Confirmed => Won't Fix ** Changed in: nova Status: Confirmed => 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/1297871 Title: Use GB instead of MB for the swap part size in Ironic Status in OpenStack Bare Metal Provisioning Service (Ironic): Won't Fix Status in OpenStack Compute (Nova): Won't Fix Bug description: Having different unit data for the parameters is not ideal, as we expect the size of the root and ephemeral partition in GB we also should expect the size of the swap partition to be in GB. In Nova they still using root_gb and swap_mb but this is something that the Nova Ironic driver should translate before sending the request to the Ironic api. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1297871/+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 1459446] [NEW] can't update dns for an ipv6 subnet
Public bug reported: It's not possible to update ipv6 subnet info using Horizon. To recreate: Setup: create a new network (Admin->System->Networks->Create Network) create an ipv6 subnet in that network (new network Detail->Create Subnet) Network Address: fdc5:f49e:fe9e::/64 IP Version IPv6 Gateway IP: fdc5:f49e:fe9e::1 click create To view the problem: Edit the subnet (Admin->System->Networks>[detail]->Edit Subnet->Subnet Details attempt to add a DNS name server fdc5:f49e:fe9e::3 An error is returned: "Error: Failed to update subnet "fdc5:f49e:fe9e::/64": Cannot update read-only attribute ipv6_ra_mode" however, it's possible to make the update using neutron subnet-update --dns-nameserver [ip] [id] ** Affects: horizon Importance: Undecided Assignee: Doug Fish (drfish) Status: New ** Changed in: horizon Assignee: (unassigned) => Doug Fish (drfish) -- 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/1459446 Title: can't update dns for an ipv6 subnet Status in OpenStack Dashboard (Horizon): New Bug description: It's not possible to update ipv6 subnet info using Horizon. To recreate: Setup: create a new network (Admin->System->Networks->Create Network) create an ipv6 subnet in that network (new network Detail->Create Subnet) Network Address: fdc5:f49e:fe9e::/64 IP Version IPv6 Gateway IP: fdc5:f49e:fe9e::1 click create To view the problem: Edit the subnet (Admin->System->Networks>[detail]->Edit Subnet->Subnet Details attempt to add a DNS name server fdc5:f49e:fe9e::3 An error is returned: "Error: Failed to update subnet "fdc5:f49e:fe9e::/64": Cannot update read-only attribute ipv6_ra_mode" however, it's possible to make the update using neutron subnet-update --dns-nameserver [ip] [id] To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1459446/+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 1459442] [NEW] JSCS Cleanup
Public bug reported: We need to do some cleanup before we can use JSCS globally (turned on in this patch: https://review.openstack.org/#/c/186154/). We are using those the JSCS Rules listed by John Papa here: https://github.com/johnpapa/angular-styleguide#jscs ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1459442 Title: JSCS Cleanup Status in OpenStack Dashboard (Horizon): New Bug description: We need to do some cleanup before we can use JSCS globally (turned on in this patch: https://review.openstack.org/#/c/186154/). We are using those the JSCS Rules listed by John Papa here: https://github.com/johnpapa/angular-styleguide#jscs To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1459442/+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 1459427] [NEW] VPNaaS: Certificate support for IPSec
Public bug reported: Since Barbican provides certificate management/storage, and LBaaS has successfully used the certificates, this RFE proposes to provide certificate support for VPN IPSec site-to-site connections. The expectation is that the user would use Barbican to create the certificate, and then reference the certificate when creating an IPSec connection. This would require an REST/CLI API change to accept certificate ID vs PSK, minor database change to store the certificate ID, *Swan driver modifications to apply the certificate to the template, and unit/functional test updates for these changes. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1459427 Title: VPNaaS: Certificate support for IPSec Status in OpenStack Neutron (virtual network service): New Bug description: Since Barbican provides certificate management/storage, and LBaaS has successfully used the certificates, this RFE proposes to provide certificate support for VPN IPSec site-to-site connections. The expectation is that the user would use Barbican to create the certificate, and then reference the certificate when creating an IPSec connection. This would require an REST/CLI API change to accept certificate ID vs PSK, minor database change to store the certificate ID, *Swan driver modifications to apply the certificate to the template, and unit/functional test updates for these changes. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1459427/+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 1459423] [NEW] VPNaaS: Allow multiple local subnets for IPSec
Public bug reported: Currently, VPNaaS IPsec site to site connections may be created with one or more peer (right side) subnets specified (as CIDRs). However, for the local (left) side, only a single subnet can be specified. The reference OpenSwan/StrongSwan implementations will support multiple subnets on the local side, and this RFE is proposing to provide that support. This requires the following changes: REST API === Modify the API to not specify the local subnet on the VPN service create API, and instead, require the local subnet(s) to be specified on the IPSec connection API, in a similar fashion to what is done for remote CIDRs. Validation can make sure that there is at least one local CIDR, and all subnets in the connection are using the same IP version. This involves a backward incompatible API change, so will go to v2.0, and provide support for 1.0 in the code base. NEUTRON CLIENT == The CLI client could change from: neutron vpn-service-create ROUTER SUBNET neutron ipsec-site-connection-create ... --vpnservice-id VPNSERVICE --ikepolicy-id IKEPOLICY --ipsecpolicy-id IPSECPOLICY --peer-address PEER_ADDRESS --peer-id PEER_ID --peer-cidr PEER_CIDRS --psk PSK to: neutron vpn-service-create ROUTER neutron ipsec-site-connection-create ... --vpnservice-id VPNSERVICE --ikepolicy-id IKEPOLICY --ipsecpolicy-id IPSECPOLICY --peer-address PEER_ADDRESS --peer-id PEER_ID --peer-cidr PEER_CIDRS --local-cidr LOCAL_CIDRS --psk PSK DATABASE = The local CIDRs could be added to the IPSec connection table. Migration needed for this change. DRIVER == Besides passing the local CIDR information from service to device driver (along with existing info), the device driver needs to apply this information to the *Swan template in the same manner as is done for peer CIDR information. DOCS Update the API reference pages for VPN service create and IPSec connection create. Update existing Wiki how-to pages. ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1459423 Title: VPNaaS: Allow multiple local subnets for IPSec Status in OpenStack Neutron (virtual network service): New Bug description: Currently, VPNaaS IPsec site to site connections may be created with one or more peer (right side) subnets specified (as CIDRs). However, for the local (left) side, only a single subnet can be specified. The reference OpenSwan/StrongSwan implementations will support multiple subnets on the local side, and this RFE is proposing to provide that support. This requires the following changes: REST API === Modify the API to not specify the local subnet on the VPN service create API, and instead, require the local subnet(s) to be specified on the IPSec connection API, in a similar fashion to what is done for remote CIDRs. Validation can make sure that there is at least one local CIDR, and all subnets in the connection are using the same IP version. This involves a backward incompatible API change, so will go to v2.0, and provide support for 1.0 in the code base. NEUTRON CLIENT == The CLI client could change from: neutron vpn-service-create ROUTER SUBNET neutron ipsec-site-connection-create ... --vpnservice-id VPNSERVICE --ikepolicy-id IKEPOLICY --ipsecpolicy-id IPSECPOLICY --peer-address PEER_ADDRESS --peer-id PEER_ID --peer-cidr PEER_CIDRS --psk PSK to: neutron vpn-service-create ROUTER neutron ipsec-site-connection-create ... --vpnservice-id VPNSERVICE --ikepolicy-id IKEPOLICY --ipsecpolicy-id IPSECPOLICY --peer-address PEER_ADDRESS
[Yahoo-eng-team] [Bug 1459412] [NEW] ldap and fernet token gives ValueError('badly formed hexadecimal UUID string')
Public bug reported: When playing with some keystone deployment alternatives I stumble on a keystone issue: > 2015-05-27 12:11:52.946 57 DEBUG keystone.common.ldap.core [-] LDAP search: > base=ou=Groups,dc=acme,dc=org scope=1 > filterstr=(&(&(objectClass=groupOfNames)(member=uid=john,ou=Users,dc=acme,dc=org))(objectClass=groupOfNames)) > attrs=['ou', 'cn', 'description'] attrsonly=0 search_s > /usr/lib/python2.7/dist-packages/keystone/common/ldap/core.py:931 > 2015-05-27 12:11:52.946 57 DEBUG keystone.common.ldap.core [-] LDAP unbind > unbind_s /usr/lib/python2.7/dist-packages/keystone/common/ldap/core.py:904 > 2015-05-27 12:11:52.946 57 DEBUG keystone.identity.core [-] ID Mapping - > Domain ID: default, Default Driver: True, Domains: False, UUIDs: False, > Compatible IDs: True _set_domain_id_and_mapping > /usr/lib/python2.7/dist-packages/keystone/identity/core.py:492 > 2015-05-27 12:11:52.955 57 ERROR > keystone.token.providers.fernet.token_formatters [-] john > 2015-05-27 12:11:52.955 57 ERROR keystone.common.wsgi [-] badly formed > hexadecimal UUID string > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi Traceback (most recent > call last): > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi File > "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 239, in > __call__ > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi result = > method(context, **params) > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi File > "/usr/lib/python2.7/dist-packages/keystone/auth/controllers.py", line 397, in > authenticate_for_token > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi > parent_audit_id=token_audit_id) > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi File > "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 344, in > issue_v3_token > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi parent_audit_id) > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi File > "/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/core.py", > line 198, in issue_v3_token > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi > federated_info=federated_dict) > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi File > "/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/token_formatters.py", > line 133, in create_token > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi audit_ids) > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi File > "/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/token_formatters.py", > line 416, in assemble > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi b_user_id = > cls.convert_uuid_hex_to_bytes(user_id) > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi File > "/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/token_formatters.py", > line 239, in convert_uuid_hex_to_bytes > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi uuid_obj = > uuid.UUID(uuid_string) > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi File > "/usr/lib/python2.7/uuid.py", line 134, in __init__ > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi raise > ValueError('badly formed hexadecimal UUID string') > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi ValueError: badly > formed hexadecimal UUID string > 2015-05-27 12:11:52.955 57 TRACE keystone.common.wsgi > 2015-05-27 12:11:52.958 57 INFO eventlet.wsgi.server [-] 172.17.0.26 - - > [27/May/2015 12:11:52] "POST /v3/auth/tokens HTTP/1.1" 500 490 0.029590 Switching to UUID tokens it works. Switching to SQL Identity backend and fernet tokens works. The combination of LDAP identity backend and fernet tokens gives me the above log for any request with name/password. Reproducable always. I have a very minimalistic "cloud" setup with only 2 or 3 docker containers. One with the SQL DB, one for Keystone and optionally one for LDAP. I use Ubuntu 15.04 as base image for my containers that includes Kilo. I've patched keystone with the following changeset to make it work (with LDAP): commit 2c6db4a3bb9e1718744b0e5b03af050fd2866182 Author: Edmund Rhudy Date: Thu May 21 12:42:40 2015 -0400 Make sure LDAP filter is constructed correctly ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1459412 Title: ldap and fernet token gives ValueError('badly formed hexadecimal UUID string') Status in OpenStack Identity (Keystone): New Bug description: When playing with some keystone deployment alternatives I stumble on a keystone issue: > 2015-05-27 12:11:52.946 57 DEBUG keystone.common.ldap.core [-] LDAP search: base=ou=Groups,dc=acme,dc=org scope=1 filterstr=(&(&(objectClass=groupOfNames)(member=uid=john,ou=Users,dc=acme,dc=org))(objectClass=groupOfNames))
[Yahoo-eng-team] [Bug 1459399] [NEW] Nova + Ceph: resize-instance doesn't resize anything, lies about it
Public bug reported: Resizing Ceph-backed instances seems to be completely non-functional Steps to reproduce (in devstack with ceph enabled): 1. Boot an instance against m1.nano 2. Run "rbd -p vms ls -l" and note the size of the volume 3. Resize the instance to m1.tiny, and confirm the resize 4. Run "rbd -p vms ls -l" and note the size of the volume Expected behavior: Nova should report success, and the volume should report using ~1GB in size Actual behavior: Nova reports success, but the image does not change size. ** Affects: nova Importance: Undecided Status: New ** Description changed: Resizing Ceph-backed instances seems to be completely non-functional - Steps to reproduce: + Steps to reproduce (in devstack with ceph enabled): 1. Boot an instance against m1.nano 2. Run "rbd -p vms ls -l" and note the size of the volume 3. Resize the instance to m1.small, and confirm the resize 4. Run "rbd -p vms ls -l" and note the size of the volume Expected behavior: Nova should report success, and the volume should report using ~20GB in size Actual behavior: Nova reports success, but the image does not change size. ** Description changed: Resizing Ceph-backed instances seems to be completely non-functional Steps to reproduce (in devstack with ceph enabled): 1. Boot an instance against m1.nano 2. Run "rbd -p vms ls -l" and note the size of the volume - 3. Resize the instance to m1.small, and confirm the resize + 3. Resize the instance to m1.tiny, and confirm the resize 4. Run "rbd -p vms ls -l" and note the size of the volume Expected behavior: - Nova should report success, and the volume should report using ~20GB in + Nova should report success, and the volume should report using ~1GB in size Actual behavior: Nova reports success, but the image does not change size. -- 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/1459399 Title: Nova + Ceph: resize-instance doesn't resize anything, lies about it Status in OpenStack Compute (Nova): New Bug description: Resizing Ceph-backed instances seems to be completely non-functional Steps to reproduce (in devstack with ceph enabled): 1. Boot an instance against m1.nano 2. Run "rbd -p vms ls -l" and note the size of the volume 3. Resize the instance to m1.tiny, and confirm the resize 4. Run "rbd -p vms ls -l" and note the size of the volume Expected behavior: Nova should report success, and the volume should report using ~1GB in size Actual behavior: Nova reports success, but the image does not change size. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459399/+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 1459400] [NEW] Modal form is not working anymore
Public bug reported: With the latest upstream, modal form seems not working anymore. See attached ** Affects: horizon Importance: Undecided Assignee: Kahou Lei (kahou82) Status: New ** Attachment added: "Screen Shot 2015-05-27 at 12.13.15 PM.png" https://bugs.launchpad.net/bugs/1459400/+attachment/4405768/+files/Screen%20Shot%202015-05-27%20at%2012.13.15%20PM.png -- 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/1459400 Title: Modal form is not working anymore Status in OpenStack Dashboard (Horizon): New Bug description: With the latest upstream, modal form seems not working anymore. See attached To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1459400/+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 1457554] Re: host-evacuate-live doesn't limit number of servers evacuated simultaneously from a host
** Also affects: nova Importance: Undecided Status: New ** No longer affects: python-novaclient -- 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/1457554 Title: host-evacuate-live doesn't limit number of servers evacuated simultaneously from a host Status in OpenStack Compute (Nova): New Bug description: Attempting to evacuate too many servers from a single host simultaneously could result in bandwidth starvation. Instances dirty their memory faster than they can be migrated, resulting in instances perpetually stuck in the migrating state. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1457554/+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 1459386] [NEW] [data processing] All "Create" buttons are resulting in non-modal form
Public bug reported: *critical for data processing* In the Data Processing UI (Sahara), in each of the panels that have "Create X" buttons to create each object, those create buttons are currently resulting in a non-modal form that is broken. ** Affects: horizon Importance: Undecided Status: New ** Tags: sahara -- 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/1459386 Title: [data processing] All "Create" buttons are resulting in non-modal form Status in OpenStack Dashboard (Horizon): New Bug description: *critical for data processing* In the Data Processing UI (Sahara), in each of the panels that have "Create X" buttons to create each object, those create buttons are currently resulting in a non-modal form that is broken. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1459386/+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 1459382] [NEW] Fernet tokens can fail with LDAP identity backends
Public bug reported: It is possible for Keystone to fail to issue tokens when using an external identity backend, like LDAP, if the user IDs of a different format than UUID. This is because the Fernet token formatter attempts to convert the UUID to bytes before packing the payload. This is done to save space and results in a shorter token. When using an LDAP backend that doesn't use UUID format for the user IDs, we get a ValueError because UUID can't convert whenever the ID is to UUID.bytes [0]. We have to do something similar with the default domain in the case that it's not a uuid, same with federated user IDs [1], which we should probably do in this case. Related stacktrace [2]. [0] https://github.com/openstack/keystone/blob/e5f2d88e471ac3595c4ea0e28f27493687a87588/keystone/token/providers/fernet/token_formatters.py#L415 [1] https://github.com/openstack/keystone/blob/e5f2d88e471ac3595c4ea0e28f27493687a87588/keystone/token/providers/fernet/token_formatters.py#L509 [2] http://lists.openstack.org/pipermail/openstack/2015-May/012885.html ** Affects: keystone Importance: High Assignee: Lance Bragstad (lbragstad) Status: In Progress ** Tags: fernet ** Tags added: fernet ** Changed in: keystone Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1459382 Title: Fernet tokens can fail with LDAP identity backends Status in OpenStack Identity (Keystone): In Progress Bug description: It is possible for Keystone to fail to issue tokens when using an external identity backend, like LDAP, if the user IDs of a different format than UUID. This is because the Fernet token formatter attempts to convert the UUID to bytes before packing the payload. This is done to save space and results in a shorter token. When using an LDAP backend that doesn't use UUID format for the user IDs, we get a ValueError because UUID can't convert whenever the ID is to UUID.bytes [0]. We have to do something similar with the default domain in the case that it's not a uuid, same with federated user IDs [1], which we should probably do in this case. Related stacktrace [2]. [0] https://github.com/openstack/keystone/blob/e5f2d88e471ac3595c4ea0e28f27493687a87588/keystone/token/providers/fernet/token_formatters.py#L415 [1] https://github.com/openstack/keystone/blob/e5f2d88e471ac3595c4ea0e28f27493687a87588/keystone/token/providers/fernet/token_formatters.py#L509 [2] http://lists.openstack.org/pipermail/openstack/2015-May/012885.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1459382/+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 1459370] [NEW] neutron-db-migration crash at upgrade 26b54cf9024d -> 14be42f3d0a5, Add default security group table
Public bug reported: When i run this on empty db : ``` neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head ``` I have this error : ``` INFO [alembic.migration] Running upgrade 26b54cf9024d -> 14be42f3d0a5, Add default security group table Traceback (most recent call last): File "/usr/bin/neutron-db-manage", line 10, in sys.exit(main()) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 238, in main CONF.command.func(config, CONF.command.name) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 106, in do_upgrade do_alembic_command(config, cmd, revision, sql=CONF.command.sql) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 72, in do_alembic_command getattr(alembic_command, cmd)(config, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/alembic/command.py", line 125, in upgrade script.run_env() File "/usr/lib/python2.7/dist-packages/alembic/script.py", line 203, in run_env util.load_python_file(self.dir, 'env.py') File "/usr/lib/python2.7/dist-packages/alembic/util.py", line 212, in load_python_file module = load_module_py(module_id, path) File "/usr/lib/python2.7/dist-packages/alembic/compat.py", line 58, in load_module_py mod = imp.load_source(module_id, path, fp) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py", line 109, in run_migrations_online() File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py", line 100, in run_migrations_online context.run_migrations() File "", line 7, in run_migrations File "/usr/lib/python2.7/dist-packages/alembic/environment.py", line 688, in run_migrations self.get_context().run_migrations(**kw) File "/usr/lib/python2.7/dist-packages/alembic/migration.py", line 258, in run_migrations change(**kw) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/versions/14be42f3d0a5_default_sec_group_table.py", line 62, in upgrade ins = table.insert(inline=True).from_select(['tenant_id', AttributeError: 'NoneType' object has no attribute 'insert' ``` ``` dpkg -l | grep neutron ii neutron-common 2015.1.0-2~bpo8+1 all OpenStack virtual network service - common files ii neutron-dhcp-agent 2015.1.0-2~bpo8+1 all OpenStack virtual network service - DHCP agent ii neutron-l3-agent2015.1.0-2~bpo8+1 all OpenStack virtual network service - l3 agent ii neutron-lbaas-agent 2015.1.0-2~bpo8+1 all OpenStack virtual network service - lbass agent ii neutron-metadata-agent 2015.1.0-2~bpo8+1 all OpenStack virtual network service - metadata agent ii neutron-openvswitch-agent 2015.1.0-2~bpo8+1 all OpenStack virtual network service - Open vSwitch agent ii neutron-plugin-openvswitch-agent2015.1.0-2~bpo8+1 all transitional dummy package for switching to Neutron OpenVswitch agent. ii neutron-server 2015.1.0-2~bpo8+1 all OpenStack virtual network service - server ii python-neutron 2015.1.0-2~bpo8+1 all OpenStack virtual network service - Python library ii python-neutronclient2.4.0-1~bpo8+1 all client API library for Neutron ``` file : http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/alembic_migrations/versions/14be42f3d0a5_default_sec_group_table.py?id=79c97120de9cff4d0992b5d41ff4bbf05e890f89 ** 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/1459370 Title: neutron-db-migration crash at upgrade 26b54cf9024d -> 14be42f3d0a5, Add default security group table Status in OpenStack Neutron (virtual network service): New Bug description: When i run this on empty db : ``` neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head ``` I have this error : ``` INFO [alembic.migration] Running upgrade 26b54cf9024d -> 14be42f3d0a5, Add default security group table Traceback (most recent call last): File "/usr/bin/neutron-db-manage", line 10, in sys.exit(main()) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 238, in main CONF.command.func(config, CONF.command.name) File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 106, in do_upgrade do_alembic_co
[Yahoo-eng-team] [Bug 1459361] [NEW] VM created even though ephemeral disk creation failed.
Public bug reported: When creating a vm qemu-nbd returned error code and created ephemeral disk with 5 gigs instead of requested 350gigs. After nova rootwrap returned non-0 code I assume vm creation should fail. 1. Openstack version: ii nova-compute 1:2014.2-fuel6.0~mira19 OpenStack Compute - compute node base 2. Log files: attached nova-compute.log 3. Reproduce steps: it happened once, don't know how to reproduce Expeceted result: vm ends up in error state Actual result: vm started but with smaller disk than requested ** Affects: nova Importance: Undecided Status: New ** Attachment added: "nova_error.txt" https://bugs.launchpad.net/bugs/1459361/+attachment/4405674/+files/nova_error.txt -- 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/1459361 Title: VM created even though ephemeral disk creation failed. Status in OpenStack Compute (Nova): New Bug description: When creating a vm qemu-nbd returned error code and created ephemeral disk with 5 gigs instead of requested 350gigs. After nova rootwrap returned non-0 code I assume vm creation should fail. 1. Openstack version: ii nova-compute 1:2014.2-fuel6.0~mira19 OpenStack Compute - compute node base 2. Log files: attached nova-compute.log 3. Reproduce steps: it happened once, don't know how to reproduce Expeceted result: vm ends up in error state Actual result: vm started but with smaller disk than requested To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459361/+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 1304333] Re: [SRU] Instance left stuck in transitional POWERING state
This bug was fixed in the package nova - 1:2014.1.4-0ubuntu2.1 --- nova (1:2014.1.4-0ubuntu2.1) trusty; urgency=medium * Ensure that compute manager restarts during instance power operations don't leave instances stuck in transitional task states (LP: #1304333): - d/p/recover-from-power-state-on-compute.patch Cherry pick backport of upstream fix from OpenStack >= Juno. -- Edward Hope-MorleyWed, 22 Apr 2015 09:51:28 +0100 ** Changed in: nova (Ubuntu Trusty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1304333 Title: [SRU] Instance left stuck in transitional POWERING state Status in OpenStack Compute (Nova): Fix Released Status in nova package in Ubuntu: Fix Released Status in nova source package in Trusty: Fix Released Bug description: If a compute manager is stopped / fails during POWERING-ON or POWERING-OFF operations then the instance will be left stuck in a this transitional task_state. --- --- --- --- --- --- --- [Impact] * We are backporting this to Icehouse since nova currently fails to resolve instance state when service is restarted. It is not expected to impact normal operational behaviour in any way. [Test Case] * Deploy cloud incl. nova-compute and rabbitmq and create some instances. * Perform actions on those instances that cause state to change * Restart nova-compute and once restarted check that nova instances are in expected state. [Regression Potential] * None that I can see. This is hopefully a very low impact patch and I have tested in my local cloud environment with successful results. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1304333/+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 1458945] Re: Use graduated oslo.policy instead of oslo-incubator code
** No longer affects: designate -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1458945 Title: Use graduated oslo.policy instead of oslo-incubator code Status in OpenStack Key Management (Barbican): New Status in OpenStack Telemetry (Ceilometer): New Status in Cinder: New Status in OpenStack Congress: New Status in OpenStack Dashboard (Horizon): New Status in MagnetoDB - key-value storage service for OpenStack: New Status in OpenStack Magnum: New Status in Mistral: New Status in Murano: New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): New Status in Rally: Invalid Status in Openstack Database (Trove): Invalid Bug description: The Policy code is now be managed as a library, named oslo.policy. If there is a CVE level defect, deploying a fix should require deploying a new version of the library, not syncing each individual project. All the projects in the OpenStack ecosystem that are using the policy code from oslo-incubator should use the new library. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1458945/+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 1453906] Re: Implement Routing Networks in Neutron
Gotta get this one out of here too, I guess. ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1453906 Title: Implement Routing Networks in Neutron Status in OpenStack Neutron (virtual network service): Invalid Bug description: This feature request proposes to allow using private subnets and public subnets together on the same physical network. The private network will be used for router next-hops and other router communication. This will also allow having an L3 only routed network which spans L2 networks. This will depend on dynamic routing integration with Neutron. https://blueprints.launchpad.net/neutron/+spec/routing-networks To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1453906/+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 1453921] Re: Implement Address Scopes
I'm sorry to offend you with this. ** Changed in: neutron Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1453921 Title: Implement Address Scopes Status in OpenStack Neutron (virtual network service): Invalid Bug description: Make address scopes a first class thing in Neutron and make Neutron routers aware of them. Described in blueprint address-scopes To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1453921/+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 1459343] [NEW] Port security enabled=True is not respected
Public bug reported: It is possible to send traffic through port with port_security_enabled=True. Steps to reproduce. 1) Create three VMS on one network: Guest os: ubuntu-14.04 "destination" VM to ping (10.100.0.3) "router" VM to send traffic through (10.100.0.2) "source" VM that will ping "destination" VM(10.100.0.1) 2) On source VM add route to destination via router ( sudo ip route add 10.100.0.3 via 10.100.0.2) 3) On "router" VM set net.ipv4.ip_forward = 1 (sudo sysctl net.ipv4.ip_forward = 1) 4) On "destination" VM add route to 'source' via router ( sudo ip route add 10.100.0.1 via 10.100.0.2) 5) Start to ping "destination" on "source" VM. 5.1) Check traffic on all VMs ** Affects: neutron Importance: Undecided Status: New ** Tags: port-security -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1459343 Title: Port security enabled=True is not respected Status in OpenStack Neutron (virtual network service): New Bug description: It is possible to send traffic through port with port_security_enabled=True. Steps to reproduce. 1) Create three VMS on one network: Guest os: ubuntu-14.04 "destination" VM to ping (10.100.0.3) "router" VM to send traffic through (10.100.0.2) "source" VM that will ping "destination" VM(10.100.0.1) 2) On source VM add route to destination via router ( sudo ip route add 10.100.0.3 via 10.100.0.2) 3) On "router" VM set net.ipv4.ip_forward = 1 (sudo sysctl net.ipv4.ip_forward = 1) 4) On "destination" VM add route to 'source' via router ( sudo ip route add 10.100.0.1 via 10.100.0.2) 5) Start to ping "destination" on "source" VM. 5.1) Check traffic on all VMs To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1459343/+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 1443598] Re: [OSSA 2015-008] backend_argument containing a password leaked in logs (CVE-2015-3646)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1443598 Title: [OSSA 2015-008] backend_argument containing a password leaked in logs (CVE-2015-3646) Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone icehouse series: Fix Committed Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: The keystone.conf has an option backend_argument to set various options for the caching backend. As documented, some of the potential values can contain a password. Snippet from http://docs.openstack.org/developer/keystone/developing.html#dogpile- cache-based-mongodb-nosql-backend [cache] # Global cache functionality toggle. enabled = True # Referring to specific cache backend backend = keystone.cache.mongo # Backend specific configuration arguments backend_argument = db_hosts:localhost:27017 backend_argument = db_name:ks_cache backend_argument = cache_collection:cache backend_argument = username:test_user backend_argument = password:test_password As a result, passwords can be leaked to the keystone logs since the config options is not marked secret. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1443598/+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 1459279] [NEW] Wrong assertion examples in doc
Public bug reported: The "pure" SAML assertion example in [1] is not a valid assertion generated by keystone and the ECP wrapped one is missing the two new attributes "openstack_user_domain" and "openstack_project_domain". [1] https://github.com/openstack/keystone-specs/blob/master/api/v3 /identity-api-v3-os-federation-ext.rst#generating-assertions ** Affects: keystone Importance: Undecided Assignee: Rodrigo Duarte (rodrigodsousa) Status: In Progress ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1459279 Title: Wrong assertion examples in doc Status in OpenStack Identity (Keystone): In Progress Bug description: The "pure" SAML assertion example in [1] is not a valid assertion generated by keystone and the ECP wrapped one is missing the two new attributes "openstack_user_domain" and "openstack_project_domain". [1] https://github.com/openstack/keystone-specs/blob/master/api/v3 /identity-api-v3-os-federation-ext.rst#generating-assertions To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1459279/+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 1459255] [NEW] Fix the docs since Federation is no longer an extension
Public bug reported: Currently we have a documentation to enable the Federation extension [1]. Although there is some steps that are no longer needed, some of them need to be executed in order to the functionality properly work: add the "saml2" auth method, install xmlsec1 and pysaml2. These steps should be included in the main Federation doc [2] and the extension one should be removed. [1] https://github.com/openstack/keystone/blob/master/doc/source/extensions/federation.rst [2] https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst ** Affects: keystone Importance: Undecided Status: New ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1459255 Title: Fix the docs since Federation is no longer an extension Status in OpenStack Identity (Keystone): New Bug description: Currently we have a documentation to enable the Federation extension [1]. Although there is some steps that are no longer needed, some of them need to be executed in order to the functionality properly work: add the "saml2" auth method, install xmlsec1 and pysaml2. These steps should be included in the main Federation doc [2] and the extension one should be removed. [1] https://github.com/openstack/keystone/blob/master/doc/source/extensions/federation.rst [2] https://github.com/openstack/keystone/blob/master/doc/source/configure_federation.rst To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1459255/+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 1455344] Re: the deprecated compute_port option need to be removed
Why was this marked invalid? ** Changed in: keystone Importance: Undecided => Low ** Changed in: keystone Status: Invalid => Fix Committed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1455344 Title: the deprecated compute_port option need to be removed Status in OpenStack Identity (Keystone): Fix Committed Bug description: the "compute_port" option has been marked deprecated and should be remove in Liberty. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1455344/+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 1453953] Re: keystoneclient cannot log non-ascii data
>From Ken Chen in https://bugs.launchpad.net/python- keystoneclient/+bug/1457279 -- In keystoneclient/session.py file, _http_log_request method, we have below codes: if data: string_parts.append("-d '%s'" % data) logger.debug(' '.join(string_parts)) However, if data is not in ascii chars, this might cause error like: UnicodeEncodeError: 'ascii' codec can't encode character u'\\xbb' in position 10: ordinal not in range(128) This is also the reason of bug https://bugs.launchpad.net/horizon/+bug/1453953 -- ** Summary changed: - [data processing] Unable to upload job binaries + keystoneclient cannot log non-ascii data ** Project changed: horizon => python-keystoneclient ** Tags removed: sahara ** Changed in: python-keystoneclient Status: New => Triaged ** Changed in: python-keystoneclient Importance: Undecided => High -- 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/1453953 Title: keystoneclient cannot log non-ascii data Status in Python client library for Keystone: Triaged Bug description: This bug was originally written against Sahara, but it appears to be a Horizon issue instead, so I'm reporting it here. When trying to upload the spark-example.jar from the Sahara edp- examples, it fails with the message "Danger: There was an error submitting the form. Please try again." In the logs, the stack trace looks like this: Internal Server Error: /project/data_processing/job_binaries/create-job-binary Traceback (most recent call last): File "/home/croberts/src/horizon/.venv/lib/python2.7/site-packages/django/core/handlers/base.py", line 111, in get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/home/croberts/src/horizon/horizon/decorators.py", line 36, in dec return view_func(request, *args, **kwargs) File "/home/croberts/src/horizon/horizon/decorators.py", line 52, in dec return view_func(request, *args, **kwargs) File "/home/croberts/src/horizon/horizon/decorators.py", line 36, in dec return view_func(request, *args, **kwargs) File "/home/croberts/src/horizon/horizon/decorators.py", line 84, in dec return view_func(request, *args, **kwargs) File "/home/croberts/src/horizon/.venv/lib/python2.7/site-packages/django/views/generic/base.py", line 69, in view return self.dispatch(request, *args, **kwargs) File "/home/croberts/src/horizon/.venv/lib/python2.7/site-packages/django/views/generic/base.py", line 87, in dispatch return handler(request, *args, **kwargs) File "/home/croberts/src/horizon/.venv/lib/python2.7/site-packages/django/views/generic/edit.py", line 173, in post return self.form_valid(form) File "/home/croberts/src/horizon/horizon/forms/views.py", line 173, in form_valid exceptions.handle(self.request) File "/home/croberts/src/horizon/horizon/exceptions.py", line 364, in handle six.reraise(exc_type, exc_value, exc_traceback) File "/home/croberts/src/horizon/horizon/forms/views.py", line 170, in form_valid handled = form.handle(self.request, form.cleaned_data) File "/home/croberts/src/horizon/openstack_dashboard/dashboards/project/data_processing/job_binaries/forms.py", line 183, in handle _("Unable to create job binary")) File "/home/croberts/src/horizon/horizon/exceptions.py", line 364, in handle six.reraise(exc_type, exc_value, exc_traceback) File "/home/croberts/src/horizon/openstack_dashboard/dashboards/project/data_processing/job_binaries/forms.py", line 169, in handle bin_url = self.handle_internal(request, context) File "/home/croberts/src/horizon/openstack_dashboard/dashboards/project/data_processing/job_binaries/forms.py", line 216, in handle_internal _("Unable to upload job binary")) File "/home/croberts/src/horizon/horizon/exceptions.py", line 364, in handle six.reraise(exc_type, exc_value, exc_traceback) File "/home/croberts/src/horizon/openstack_dashboard/dashboards/project/data_processing/job_binaries/forms.py", line 212, in handle_internal request.FILES["job_binary_file"].read()) File "/home/croberts/src/horizon/openstack_dashboard/api/sahara.py", line 332, in job_binary_internal_create data=data) File "/home/croberts/src/horizon/.venv/lib/python2.7/site-packages/saharaclient/api/job_binary_internals.py", line 31, in create 'job_binary_internal', dump_json=False) File "/home/croberts/src/horizon/.venv/lib/python2.7/site-packages/saharaclient/api/base.py", line 110, in _update resp = self.api.put(url, **kwargs) File "/home/croberts/src/horizon/.venv/lib/python2.7/site-packages/keystoneclient/adapter.py", line 179, in put return self.request(url, 'PUT', **kwargs) File "/home/croberts/src/horizon/.venv/lib/p
[Yahoo-eng-team] [Bug 1458968] Re: stable/juno unit tests blocked: ContextualVersionConflict: (oslo.i18n 1.3.1 (/home/jenkins/workspace/periodic-glance-python27-juno/.tox/py27/lib/python2.7/site-packa
https://review.openstack.org/#/c/173123/ has merged. ** Changed in: glance Status: New => Invalid ** Changed in: keystonemiddleware Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1458968 Title: stable/juno unit tests blocked: ContextualVersionConflict: (oslo.i18n 1.3.1 (/home/jenkins/workspace/periodic-glance- python27-juno/.tox/py27/lib/python2.7/site-packages), Requirement.parse('oslo.i18n>=1.5.0'), set(['oslo.utils', 'pycadf'])) Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Status in OpenStack Identity (Keystone) Middleware: Invalid Bug description: stable/juno unit tests are failing on (multiple) dependency conflicts. Reproducible outside the gate simply running the py27 or py26 tox env locally: Tests in glance.tests.unit.test_opts fail with: ContextualVersionConflict: (oslo.i18n 1.3.1 (/home/jenkins/workspace /periodic-glance-python27-juno/.tox/py27/lib/python2.7/site-packages), Requirement.parse('oslo.i18n>=1.5.0'), set(['oslo.utils', 'pycadf'])) This isn't affecting stable/juno tempest runs of this stuff since devstack sets up libraries directly from tip of the stable branches, where requirements have been updated to avoid this. Those fixes haven't been pushed out via releases to pypi, which is what the unit tests rely on. There are two paths of conflict glance (stable/juno) (keystonemiddleware>=1.0.0,<1.4.0) -> keystonemiddleware (1.3.1) (pycadf>=0.6.0) -> pycadf (0.9.0) -> CONFLICT oslo.config>=1.9.3 # Apache-2.0 -> CONFLICT oslo.i18n>=1.5.0 # Apache-2.0 As per GR, we should be getting pycadf>=0.6.0,!=0.6.2,<0.7.0, but keystomemiddleware's uncapped dep is pulling in the newer. https://review.openstack.org/#/c/173123/ resolves the issue by adding the proper stable/juno caps to keystonemiddleware stable/juno, but it looks like those changes need to be released as keystonemiddlware 1.3.2 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1458968/+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 1458945] Re: Use graduated oslo.policy instead of oslo-incubator code
** No longer affects: manila -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1458945 Title: Use graduated oslo.policy instead of oslo-incubator code Status in OpenStack Key Management (Barbican): New Status in OpenStack Telemetry (Ceilometer): New Status in Cinder: New Status in OpenStack Congress: New Status in Designate: New Status in OpenStack Dashboard (Horizon): New Status in MagnetoDB - key-value storage service for OpenStack: New Status in OpenStack Magnum: New Status in Mistral: New Status in Murano: New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): New Status in Rally: Invalid Status in Openstack Database (Trove): Invalid Bug description: The Policy code is now be managed as a library, named oslo.policy. If there is a CVE level defect, deploying a fix should require deploying a new version of the library, not syncing each individual project. All the projects in the OpenStack ecosystem that are using the policy code from oslo-incubator should use the new library. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1458945/+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 1459179] [NEW] User heat has no access to domain default when using Keystone v3 with multi-domain-driver
Public bug reported: When using Keystone v3 with multi-domain-driver in Juno on Centos, I cann't deploy heat stack, because the heat user has no access to default domain wich runs on sql default -> SQL -> service user and heat dom -> LDAP -> AD user /var/log/heat/heat.log 2015-05-27 11:38:42.502 13632 DEBUG heat.engine.stack_lock [-] Engine 651cdcf1-49cb-4ca4-9436-35ff538666ed acquired lock on stack 22a20e5a-901b-436c-9c8c-e603bc79015b acquire /usr/lib/python2.7/site-packages/heat/engine/stack_lock.py:72 2015-05-27 11:38:42.503 13632 DEBUG keystoneclient.auth.identity.v3 [-] Making authentication request to http://172.16.89.1:5000/v3/auth/tokens get_auth_ref /usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v3.py:117 2015-05-27 11:38:42.504 13632 INFO urllib3.connectionpool [-] Starting new HTTP connection (1): 172.16.89.1 2015-05-27 11:38:42.579 13632 DEBUG urllib3.connectionpool [-] "POST /v3/auth/tokens HTTP/1.1" 401 181 _make_request /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:357 2015-05-27 11:38:42.580 13632 DEBUG keystoneclient.session [-] Request returned failure status: 401 request /usr/lib/python2.7/site-packages/keystoneclient/session.py:345 2015-05-27 11:38:42.580 13632 DEBUG keystoneclient.v3.client [-] Authorization failed. get_raw_token_from_identity_service /usr/lib/python2.7/site-packages/keystoneclient/v3/client.py:267 /var/log/keystone/keystone.log 2015-05-27 11:38:42.265 8847 DEBUG keystone.common.kvs.core [-] KVS lock acquired for: os-revoke-events acquire /usr/lib/python2.7/site-packages/keystone/common/kvs/core.py:380 2015-05-27 11:38:42.265 8847 DEBUG keystone.common.kvs.core [-] KVS lock released for: os-revoke-events release /usr/lib/python2.7/site-packages/keystone/common/kvs/core.py:399 2015-05-27 11:38:42.265 8847 DEBUG keystone.middleware.core [-] RBAC: auth_context: {'is_delegated_auth': False, 'access_token_id': None, 'user_id': u'86396c4533a044a1ab106ccaeb7e883d', 'roles': [u'heat_stack_owner', u'admin'], 'trustee_$ 2015-05-27 11:38:42.266 8847 DEBUG keystone.common.wsgi [-] arg_dict: {} __call__ /usr/lib/python2.7/site-packages/keystone/common/wsgi.py:191 2015-05-27 11:38:42.267 8847 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:validate_token() _build_policy_check_credentials /usr/lib/python2.7/site-packages/keystone/common/controller.py:55 2015-05-27 11:38:42.267 8847 DEBUG keystone.common.controller [-] RBAC: using auth context from the request environment _build_policy_check_credentials /usr/lib/python2.7/site-packages/keystone/common/controller.py:60 2015-05-27 11:38:42.270 8847 DEBUG keystone.common.kvs.core [-] KVS lock acquired for: os-revoke-events acquire /usr/lib/python2.7/site-packages/keystone/common/kvs/core.py:380 2015-05-27 11:38:42.270 8847 DEBUG keystone.common.kvs.core [-] KVS lock released for: os-revoke-events release /usr/lib/python2.7/site-packages/keystone/common/kvs/core.py:399 2015-05-27 11:38:42.270 8847 DEBUG keystone.policy.backends.rules [-] enforce identity:validate_token: {'is_delegated_auth': False, 'access_token_id': None, 'user_id': u'86396c4533a044a1ab106ccaeb7e883d', 'roles': [u'heat_stack_owner', u$ 2015-05-27 11:38:42.270 8847 DEBUG keystone.common.controller [-] RBAC: Authorization granted inner /usr/lib/python2.7/site-packages/keystone/common/controller.py:155 2015-05-27 11:38:42.273 8847 DEBUG keystone.common.kvs.core [-] KVS lock acquired for: os-revoke-events acquire /usr/lib/python2.7/site-packages/keystone/common/kvs/core.py:380 2015-05-27 11:38:42.273 8847 DEBUG keystone.common.kvs.core [-] KVS lock released for: os-revoke-events release /usr/lib/python2.7/site-packages/keystone/common/kvs/core.py:399 2015-05-27 11:38:42.274 8847 INFO eventlet.wsgi.server [-] 172.16.89.1 - - [27/May/2015 11:38:42] "GET /v3/auth/tokens HTTP/1.1" 200 7887 0.012976 2015-05-27 11:38:42.343 8849 DEBUG keystone.middleware.core [-] Auth token not in the request header. Will not build auth context. process_request /usr/lib/python2.7/site-packages/keystone/middleware/core.py:270 2015-05-27 11:38:42.345 8849 DEBUG keystone.common.wsgi [-] arg_dict: {} __call__ /usr/lib/python2.7/site-packages/keystone/common/wsgi.py:191 2015-05-27 11:38:42.441 8849 INFO eventlet.wsgi.server [-] 172.16.89.1 - - [27/May/2015 11:38:42] "POST /v3/auth/tokens HTTP/1.1" 201 7902 0.097828 2015-05-27 11:38:42.450 8852 DEBUG keystone.common.kvs.core [-] KVS lock acquired for: os-revoke-events acquire /usr/lib/python2.7/site-packages/keystone/common/kvs/core.py:380 2015-05-27 11:38:42.450 8852 DEBUG keystone.common.kvs.core [-] KVS lock released for: os-revoke-events release /usr/lib/python2.7/site-packages/keystone/common/kvs/core.py:399 2015-05-27 11:38:42.450 8852 DEBUG keystone.middleware.core [-] RBAC: auth_context: {'is_delegated_auth': False, 'access_token_id': None, 'user_id': u'c287350c73ef4410ad17326eee940c5f', 'roles': [u'heat_stack_owner', u'admin'], '
[Yahoo-eng-team] [Bug 1458945] Re: Use graduated oslo.policy instead of oslo-incubator code
** No longer affects: sahara -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1458945 Title: Use graduated oslo.policy instead of oslo-incubator code Status in OpenStack Key Management (Barbican): New Status in OpenStack Telemetry (Ceilometer): New Status in Cinder: New Status in OpenStack Congress: New Status in Designate: New Status in OpenStack Dashboard (Horizon): New Status in MagnetoDB - key-value storage service for OpenStack: New Status in OpenStack Magnum: New Status in Manila: New Status in Mistral: New Status in Murano: New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): New Status in Rally: Invalid Status in Openstack Database (Trove): Invalid Bug description: The Policy code is now be managed as a library, named oslo.policy. If there is a CVE level defect, deploying a fix should require deploying a new version of the library, not syncing each individual project. All the projects in the OpenStack ecosystem that are using the policy code from oslo-incubator should use the new library. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1458945/+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 1458945] Re: Use graduated oslo.policy instead of oslo-incubator code
** Changed in: trove Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1458945 Title: Use graduated oslo.policy instead of oslo-incubator code Status in OpenStack Key Management (Barbican): New Status in OpenStack Telemetry (Ceilometer): New Status in Cinder: New Status in OpenStack Congress: New Status in Designate: New Status in OpenStack Dashboard (Horizon): New Status in MagnetoDB - key-value storage service for OpenStack: New Status in OpenStack Magnum: New Status in Manila: New Status in Mistral: New Status in Murano: New Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): New Status in Rally: Invalid Status in OpenStack Data Processing (Sahara): New Status in Openstack Database (Trove): Invalid Bug description: The Policy code is now be managed as a library, named oslo.policy. If there is a CVE level defect, deploying a fix should require deploying a new version of the library, not syncing each individual project. All the projects in the OpenStack ecosystem that are using the policy code from oslo-incubator should use the new library. To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1458945/+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 1459144] [NEW] Enhance VMware to support VirtualVmxnet3 as network type
Public bug reported: Some devices may need to support VirtualVmxnet3 as a network. We should to make sure VMware can handle that case. ** Affects: nova Importance: Low Assignee: sahid (sahid-ferdjaoui) Status: Fix Committed ** Tags: juno-backport-potential kilo-backport-potential ** Changed in: nova Importance: Undecided => Low ** Changed in: nova Status: New => Fix Released ** Changed in: nova Status: Fix Released => Fix Committed -- 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/1459144 Title: Enhance VMware to support VirtualVmxnet3 as network type Status in OpenStack Compute (Nova): Fix Committed Bug description: Some devices may need to support VirtualVmxnet3 as a network. We should to make sure VMware can handle that case. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459144/+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 1459021] Re: nova vmware unit tests failing with oslo.vmware 0.13.0
** Changed in: nova Status: Invalid => In Progress ** Changed in: nova Assignee: (unassigned) => Matthew Gilliard (matthew-gilliard-u) -- 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/1459021 Title: nova vmware unit tests failing with oslo.vmware 0.13.0 Status in OpenStack Compute (Nova): In Progress Status in Oslo VMware library for OpenStack projects: In Progress Bug description: http://logs.openstack.org/68/184968/2/check/gate-nova- python27/e3dadf7/console.html#_2015-05-26_20_45_35_734 2015-05-26 20:45:35.734 | {4} nova.tests.unit.virt.vmwareapi.test_vm_util.VMwareVMUtilTestCase.test_create_vm_invalid_guestid [0.058940s] ... FAILED 2015-05-26 20:45:35.735 | 2015-05-26 20:45:35.735 | Captured traceback: 2015-05-26 20:45:35.735 | ~~~ 2015-05-26 20:45:35.736 | Traceback (most recent call last): 2015-05-26 20:45:35.736 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/mock.py", line 1201, in patched 2015-05-26 20:45:35.736 | return func(*args, **keywargs) 2015-05-26 20:45:35.737 | File "nova/tests/unit/virt/vmwareapi/test_vm_util.py", line 796, in test_create_vm_invalid_guestid 2015-05-26 20:45:35.737 | 'folder', config_spec, 'res-pool') 2015-05-26 20:45:35.737 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 422, in assertRaises 2015-05-26 20:45:35.738 | self.assertThat(our_callable, matcher) 2015-05-26 20:45:35.738 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 433, in assertThat 2015-05-26 20:45:35.738 | mismatch_error = self._matchHelper(matchee, matcher, message, verbose) 2015-05-26 20:45:35.738 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 483, in _matchHelper 2015-05-26 20:45:35.739 | mismatch = matcher.match(matchee) 2015-05-26 20:45:35.739 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_exception.py", line 108, in match 2015-05-26 20:45:35.739 | mismatch = self.exception_matcher.match(exc_info) 2015-05-26 20:45:35.740 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_higherorder.py", line 62, in match 2015-05-26 20:45:35.740 | mismatch = matcher.match(matchee) 2015-05-26 20:45:35.740 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 414, in match 2015-05-26 20:45:35.741 | reraise(*matchee) 2015-05-26 20:45:35.741 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_exception.py", line 101, in match 2015-05-26 20:45:35.741 | result = matchee() 2015-05-26 20:45:35.742 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 969, in __call__ 2015-05-26 20:45:35.742 | return self._callable_object(*self._args, **self._kwargs) 2015-05-26 20:45:35.742 | File "nova/virt/vmwareapi/vm_util.py", line 1280, in create_vm 2015-05-26 20:45:35.742 | task_info = session._wait_for_task(vm_create_task) 2015-05-26 20:45:35.743 | File "nova/virt/vmwareapi/driver.py", line 714, in _wait_for_task 2015-05-26 20:45:35.743 | return self.wait_for_task(task_ref) 2015-05-26 20:45:35.743 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/oslo_vmware/api.py", line 381, in wait_for_task 2015-05-26 20:45:35.744 | return evt.wait() 2015-05-26 20:45:35.744 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/eventlet/event.py", line 121, in wait 2015-05-26 20:45:35.744 | return hubs.get_hub().switch() 2015-05-26 20:45:35.745 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 294, in switch 2015-05-26 20:45:35.745 | return self.greenlet.switch() 2015-05-26 20:45:35.745 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/oslo_vmware/common/loopingcall.py", line 76, in _inner 2015-05-26 20:45:35.745 | self.f(*self.args, **self.kw) 2015-05-26 20:45:35.746 | File "/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/oslo_vmware/api.py", line 423, in _poll_task 2015-05-26 20:45:35.746 | raise