[Yahoo-eng-team] [Bug 1470356] [NEW] AttributeError on creating instance with raw image type
Public bug reported: Nova compute raises AttributeError on creating the instance with raw image type and instance goes in to error state. Steps to reproduce: 1. Set image_type = raw in [libvirt] section of nova.conf and restart nova services. 2. Create an instance using image (I have used default cirros image). $ nova boot --image 5e1659aa-6d38-44e8-aaa3-4217337436c0 --flavor 1 instance-1 3. Run $ nova list 4. Instance is in Error state and following error is logged in n-cpu logs 2015-06-30 23:13:11.174 DEBUG oslo_concurrency.lockutils [req-f66cf801-d424-4583-8270-92023c6a70a1 demo demo] Lock "8d2c340dcce68e48a75457b1e91457feed27a ef5" released by "copy_raw_image" :: held 0.431s from (pid=29182) inner /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:456 2015-06-30 23:13:11.184 ERROR nova.compute.manager [req-f66cf801-d424-4583-8270-92023c6a70a1 demo demo] [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] Instance failed to spawn 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] Traceback (most recent call last): 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/opt/stack/nova/nova/compute/manager.py", lin e 2113, in _build_resources 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] yield resources 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/opt/stack/nova/nova/compute/manager.py", lin e 1985, in _build_and_run_instance 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] block_device_info=block_device_info) 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2428, in spawn 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] admin_pass=admin_password) 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2827, in _create_image 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] instance, size, fallback_from_host) 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5968, in _try_fetch_image_cache 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] size=size) 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/opt/stack/nova/nova/virt/libvirt/imagebacken d.py", line 234, in cache 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] *args, **kwargs) 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/opt/stack/nova/nova/virt/libvirt/imagebacken d.py", line 452, in create_image 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] copy_raw_image(base, self.path, size) 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/usr/local/lib/python2.7/dist-packages/oslo_c oncurrency/lockutils.py", line 445, in inner 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] return f(*args, **kwargs) 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/opt/stack/nova/nova/virt/libvirt/imagebacken d.py", line 439, in copy_raw_image 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] disk.extend(image, size) 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/opt/stack/nova/nova/virt/disk/api.py", line 197, in extend 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] if not is_image_extendable(image): 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] File "/opt/stack/nova/nova/virt/disk/api.py", line 272, in is_image_extendable 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] utils.execute('e2label', image.file) 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943-b25e-da684edaf569] AttributeError: 'LocalFileImage' object has no attrib ute 'file' 2015-06-30 23:13:11.184 TRACE nova.compute.manager [instance: 4a4913a9-2ea9-4943 ** Affects: nova Importance: Undecided Assignee: Ankit Agrawal (ankitagrawal) Status: New ** Changed in: nova
[Yahoo-eng-team] [Bug 1470341] [NEW] Cannot remove host from aggregate if host has been deleted
Public bug reported: Kilo code Reproduce steps: 1. Assuming that we have one nova-compute node named 'icm' which is added into one aggregate named 'zhaoqin' [root@icm ~]# nova aggregate-details zhaoqin ++-+---+---++ | Id | Name| Availability Zone | Hosts | Metadata | ++-+---+---++ | 1 | zhaoqin | zhaoqin-az| 'icm' | 'availability_zone=zhaoqin-az' | ++-+---+---++ [root@icm ~]# nova service-list ++--+--++-+---++-+ | Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | ++--+--++-+---++-+ | 1 | nova-conductor | icm | internal | enabled | up| 2015-06-30T14:04:25.828383 | - | | 3 | nova-scheduler | icm | internal | enabled | up| 2015-06-30T14:04:24.525474 | - | | 4 | nova-consoleauth | icm | internal | enabled | up| 2015-06-30T14:04:24.640657 | - | | 5 | nova-compute | icm | zhaoqin-az | enabled | up| 2015-06-30T14:04:19.865857 | - | | 6 | nova-cert| icm | internal | enabled | up| 2015-06-30T14:04:25.080046 | - | ++--+--++-+---++-+ 2. Remove the nova-compute using service-delete command. However, the host is still in aggregate. [root@icm ~]# nova service-delete 5 [root@icm ~]# nova service-list ++--+--+--+-+---++-+ | Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | ++--+--+--+-+---++-+ | 1 | nova-conductor | icm | internal | enabled | up| 2015-06-30T14:05:35.826699 | - | | 3 | nova-scheduler | icm | internal | enabled | up| 2015-06-30T14:05:34.524507 | - | | 4 | nova-consoleauth | icm | internal | enabled | up| 2015-06-30T14:05:34.638234 | - | | 6 | nova-cert| icm | internal | enabled | up| 2015-06-30T14:05:35.092009 | - | ++--+--+--+-+---++-+ [root@icm ~]# nova aggregate-details zhaoqin ++-+---+---++ | Id | Name| Availability Zone | Hosts | Metadata | ++-+---+---++ | 1 | zhaoqin | zhaoqin-az| 'icm' | 'availability_zone=zhaoqin-az' | ++-+---+---++ 3. Then, attempt to remove the host from aggregate, but fails. And we can not remove this aggregate either, because it is not empty. [root@icm ~]# nova aggregate-remove-host zhaoqin icm ERROR (NotFound): Cannot remove host icm in aggregate 1: not found (HTTP 404) (Request-ID: req-b5024dbf-156a-44ee-b48e-fc53a331e05d) [root@icm ~]# nova aggregate-delete zhaoqin ERROR (BadRequest): Cannot remove host from aggregate 1. Reason: Host aggregate is not empty. (HTTP 400) (Request-ID: req-a3c5346c-9a96-49f4-a76d-a7baa768a0ef) ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1470341 Title: Cannot remove host from aggregate if host has been deleted Status in OpenStack Compute (Nova): New Bug description: Kilo code Reproduce steps: 1. Assuming that we have one nova-compute node named 'icm' which is added into one aggregate named 'zhaoqin' [root@icm ~]# nova aggregate-details zhaoqin ++-+---+---++ | Id | Name| Availability Zone | Hosts | Metadata | ++-+---+---++ | 1 | zhaoqin | zhaoqin-az| 'icm' | 'availability_zone=zhaoqin-az' | ++-+---+---++ [root@icm ~]# nova service-list ++--+--++-+---++-+ | Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason | ++--+--++-+---++-+ | 1
[Yahoo-eng-team] [Bug 1470279] Re: ofagent unittest failes for multiple mock patches
** Project changed: neutron => networking-ofagent -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1470279 Title: ofagent unittest failes for multiple mock patches Status in OpenStack Networking ofagent driver and its agent: In Progress Bug description: gate-networking-ofagent-python27 job failes with the following error. This error is caused by using multiple patches to same target. That was forbidden by https://review.openstack.org/#/c/195881/. 2015-06-30 06:35:00.771 | {0} networking_ofagent.tests.unit.ofagent.test_arp_lib.TestArpLib.test_packet_in_handler_corrupted [0.030123s] ... FAILED 2015-06-30 06:35:00.772 | 2015-06-30 06:35:00.772 | Captured traceback: 2015-06-30 06:35:00.772 | ~~~ 2015-06-30 06:35:00.772 | Traceback (most recent call last): 2015-06-30 06:35:00.772 | File "networking_ofagent/tests/unit/ofagent/test_arp_lib.py", line 311, in test_packet_in_handler_corrupted 2015-06-30 06:35:00.772 | side_effect=ValueError).start() 2015-06-30 06:35:00.772 | File "/home/jenkins/workspace/gate-networking-ofagent-python27/.tox/py27/src/neutron/neutron/tests/base.py", line 191, in new_start 2015-06-30 06:35:00.772 | ''.join(self.first_traceback.get(key, [] 2015-06-30 06:35:00.772 | File "/home/jenkins/workspace/gate-networking-ofagent-python27/.tox/py27/local/lib/python2.7/site-packages/unittest2/case.py", line 666, in fail 2015-06-30 06:35:00.772 | raise self.failureException(msg) 2015-06-30 06:35:00.772 | AssertionError: mock.patch was setup on an already patched target Mod(ryu.lib.packet.packet).Packet. Stop the original patch before starting a new one. Traceback of 1st patch: File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main 2015-06-30 06:35:00.773 | "__main__", fname, loader, pkg_name) 2015-06-30 06:35:00.773 | File "/usr/lib/python2.7/runpy.py", line 72, in _run_code 2015-06-30 06:35:00.773 | exec code in run_globals 2015-06-30 06:35:00.773 | File "/home/jenkins/workspace/gate-networking-ofagent-python27/.tox/py27/lib/python2.7/site-packages/subunit/run.py", line 149, in 2015-06-30 06:35:00.773 | main() The wole log can be got from the following address. http://logs.openstack.org/00/184900/3/check/gate-networking-ofagent- python27/18ee891/console.html To manage notifications about this bug go to: https://bugs.launchpad.net/networking-ofagent/+bug/1470279/+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 1470337] [NEW] Some aspects of subnets not validated when using subnet pools
Public bug reported: It looks like _validate_subnet is not called when allocating from a subnet pool. See here [1] for a discussion about it. [1] https://review.openstack.org/#/c/153236/89/neutron/db/db_base_plugin_v2.py ** Affects: neutron Importance: Undecided Assignee: Ryan Tidwell (ryan-tidwell) Status: New ** Tags: l3-ipam-dhcp ** Tags added: l3-dvr-backlog ** Tags removed: l3-dvr-backlog ** Tags added: l3-ipam-dhcp ** Changed in: neutron Assignee: (unassigned) => Ryan Tidwell (ryan-tidwell) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1470337 Title: Some aspects of subnets not validated when using subnet pools Status in OpenStack Neutron (virtual network service): New Bug description: It looks like _validate_subnet is not called when allocating from a subnet pool. See here [1] for a discussion about it. [1] https://review.openstack.org/#/c/153236/89/neutron/db/db_base_plugin_v2.py To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1470337/+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 1469749] Re: RamFilter logging partially considers ram-allocation-ratio
The log message contains the information required, The hypervisors has 10148 MB Ram of which 480.4 MB is usable. The instance requires 2048MB. ** Changed in: nova Status: New => 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/1469749 Title: RamFilter logging partially considers ram-allocation-ratio Status in OpenStack Compute (Nova): Won't Fix Bug description: Package: nova-scheduler Version: 1:2014.1.4-0ubuntu2.1 RamFilter accurately skips a host because RAM resource is not enough for requested VM. However, I think log should be more explicit on numbers, taking into account ram-allocation-ratio can be different from 1.0. Log excerpt: 2015-06-29 12:04:21.422 15708 DEBUG nova.scheduler.filters.ram_filter [req-d14d9f04-c2b1-42be-b5b9-669318bb0030 3cca8ee6898e42f287adbd4f5dac1801 a0ae7f82f577413ab0d73f3dc09fb906] (hostname, hostname.tld) ram:10148 disk:264192 io_ops:0 instances:39 does not have 2048 MB usable ram, it only has 480.4 MB usable ram. host_passes /usr/lib/python2.7/dist-packages/nova/scheduler/filters/ram_filter.py:60 On log above, RAM says 10148 (MB), which seems enough for a 2048MB VM. First number (10148) is calculated as: TotalMB - UsedMB. Additional (real) number should be: TotalMB * RamAllocRatio - UsedMB. In this case, ram-allocatioin-ratio is 0.9, which results in 480.4MB. Please let me know if you'd need more details. Cheers, -Alvaro. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1469749/+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 1470302] [NEW] gate-nova-python27 fails with "RuntimeError: maximum recursion depth exceeded"
Public bug reported: Review: https://review.openstack.org/#/c/194325/ failed with $subject Logstash: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiUnVudGltZUVycm9yOiBtYXhpbXVtIHJlY3Vyc2lvbiBkZXB0aCBleGNlZWRlZFwiIEFORCB0YWdzOlwiY29uc29sZVwiIEFORCBidWlsZF9xdWV1ZTpcImdhdGVcIiBBTkQgYnVpbGRfbmFtZTpcImdhdGUtbm92YS1weXRob24yN1wiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDM1NzE1Njg3MDU0LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9 Possibly related to: https://review.openstack.org/#/c/197176 ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1470302 Title: gate-nova-python27 fails with "RuntimeError: maximum recursion depth exceeded" Status in OpenStack Compute (Nova): New Bug description: Review: https://review.openstack.org/#/c/194325/ failed with $subject Logstash: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiUnVudGltZUVycm9yOiBtYXhpbXVtIHJlY3Vyc2lvbiBkZXB0aCBleGNlZWRlZFwiIEFORCB0YWdzOlwiY29uc29sZVwiIEFORCBidWlsZF9xdWV1ZTpcImdhdGVcIiBBTkQgYnVpbGRfbmFtZTpcImdhdGUtbm92YS1weXRob24yN1wiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDM1NzE1Njg3MDU0LCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9 Possibly related to: https://review.openstack.org/#/c/197176 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1470302/+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 1467560] Re: RFE: add instance uuid field to nova.quota_usages table
This is reported against Icehouse which is closed for development. Please reproduce with with Kilo or liberty-1 and reopen ** Changed in: nova Status: New => 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/1467560 Title: RFE: add instance uuid field to nova.quota_usages table Status in OpenStack Compute (Nova): Won't Fix Bug description: In Icehouse, the nova.quota_usages table frequently gets out-of-sync with the currently active/stopped instances in a tenant/project, specifically, there are times when the instance will be set to terminated/deleted in the instances table and the quota_usages table will retain the data, counting against the tenant's total quota. As far as I can tell there is no way to correlate instances.uuid with the records in nova.quota_usages. I propose adding an instance uuid column to make future cleanup of this table easier. I also propose a housecleaning task that does this clean up automatically. Thanks, Dan To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1467560/+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 1470279] [NEW] ofagent unittest failes for multiple mock patches
Public bug reported: gate-networking-ofagent-python27 job failes with the following error. This error is caused by using multiple patches to same target. That was forbidden by https://review.openstack.org/#/c/195881/. 2015-06-30 06:35:00.771 | {0} networking_ofagent.tests.unit.ofagent.test_arp_lib.TestArpLib.test_packet_in_handler_corrupted [0.030123s] ... FAILED 2015-06-30 06:35:00.772 | 2015-06-30 06:35:00.772 | Captured traceback: 2015-06-30 06:35:00.772 | ~~~ 2015-06-30 06:35:00.772 | Traceback (most recent call last): 2015-06-30 06:35:00.772 | File "networking_ofagent/tests/unit/ofagent/test_arp_lib.py", line 311, in test_packet_in_handler_corrupted 2015-06-30 06:35:00.772 | side_effect=ValueError).start() 2015-06-30 06:35:00.772 | File "/home/jenkins/workspace/gate-networking-ofagent-python27/.tox/py27/src/neutron/neutron/tests/base.py", line 191, in new_start 2015-06-30 06:35:00.772 | ''.join(self.first_traceback.get(key, [] 2015-06-30 06:35:00.772 | File "/home/jenkins/workspace/gate-networking-ofagent-python27/.tox/py27/local/lib/python2.7/site-packages/unittest2/case.py", line 666, in fail 2015-06-30 06:35:00.772 | raise self.failureException(msg) 2015-06-30 06:35:00.772 | AssertionError: mock.patch was setup on an already patched target Mod(ryu.lib.packet.packet).Packet. Stop the original patch before starting a new one. Traceback of 1st patch: File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main 2015-06-30 06:35:00.773 | "__main__", fname, loader, pkg_name) 2015-06-30 06:35:00.773 | File "/usr/lib/python2.7/runpy.py", line 72, in _run_code 2015-06-30 06:35:00.773 | exec code in run_globals 2015-06-30 06:35:00.773 | File "/home/jenkins/workspace/gate-networking-ofagent-python27/.tox/py27/lib/python2.7/site-packages/subunit/run.py", line 149, in 2015-06-30 06:35:00.773 | main() The wole log can be got from the following address. http://logs.openstack.org/00/184900/3/check/gate-networking-ofagent- python27/18ee891/console.html ** 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/1470279 Title: ofagent unittest failes for multiple mock patches Status in OpenStack Neutron (virtual network service): New Bug description: gate-networking-ofagent-python27 job failes with the following error. This error is caused by using multiple patches to same target. That was forbidden by https://review.openstack.org/#/c/195881/. 2015-06-30 06:35:00.771 | {0} networking_ofagent.tests.unit.ofagent.test_arp_lib.TestArpLib.test_packet_in_handler_corrupted [0.030123s] ... FAILED 2015-06-30 06:35:00.772 | 2015-06-30 06:35:00.772 | Captured traceback: 2015-06-30 06:35:00.772 | ~~~ 2015-06-30 06:35:00.772 | Traceback (most recent call last): 2015-06-30 06:35:00.772 | File "networking_ofagent/tests/unit/ofagent/test_arp_lib.py", line 311, in test_packet_in_handler_corrupted 2015-06-30 06:35:00.772 | side_effect=ValueError).start() 2015-06-30 06:35:00.772 | File "/home/jenkins/workspace/gate-networking-ofagent-python27/.tox/py27/src/neutron/neutron/tests/base.py", line 191, in new_start 2015-06-30 06:35:00.772 | ''.join(self.first_traceback.get(key, [] 2015-06-30 06:35:00.772 | File "/home/jenkins/workspace/gate-networking-ofagent-python27/.tox/py27/local/lib/python2.7/site-packages/unittest2/case.py", line 666, in fail 2015-06-30 06:35:00.772 | raise self.failureException(msg) 2015-06-30 06:35:00.772 | AssertionError: mock.patch was setup on an already patched target Mod(ryu.lib.packet.packet).Packet. Stop the original patch before starting a new one. Traceback of 1st patch: File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main 2015-06-30 06:35:00.773 | "__main__", fname, loader, pkg_name) 2015-06-30 06:35:00.773 | File "/usr/lib/python2.7/runpy.py", line 72, in _run_code 2015-06-30 06:35:00.773 | exec code in run_globals 2015-06-30 06:35:00.773 | File "/home/jenkins/workspace/gate-networking-ofagent-python27/.tox/py27/lib/python2.7/site-packages/subunit/run.py", line 149, in 2015-06-30 06:35:00.773 | main() The wole log can be got from the following address. http://logs.openstack.org/00/184900/3/check/gate-networking-ofagent- python27/18ee891/console.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1470279/+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 1470108] Re: Gate upgrade test juno->kilo fails on oslo.serialization dependency mismatch for keystonemiddleware
Thanks to Matthew Treinish and Morgan Fainberg. the issue was analyzed and properly fixed. The version of oslo.serialization of python-keystoneclient from the stable/kilo branch and the one from keystone were not compatible. This was fixed by a new version of python-keystoneclient for kilo (1.3.2): http://lists.openstack.org/pipermail/openstack-announce/2015-June/000406.html The usage of the new client for kilo fixes the issue; the review which was failing is now working (and was merged): https://review.openstack.org/#/c/195657/ http://logs.openstack.org/57/195657/1/gate/gate-grenade-dsvm/32036b3/logs/grenade.sh.txt.gz For more details, see the channel logs: http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2015-06-30.log.html#t2015-06-30T14:25:43 This bug has been properly assigned to python-keystoneclient (and removed from horizon) for archiving purposes. ** No longer affects: horizon ** Also affects: python-keystoneclient Importance: Undecided Status: New ** No longer affects: grenade ** Changed in: python-keystoneclient Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1470108 Title: Gate upgrade test juno->kilo fails on oslo.serialization dependency mismatch for keystonemiddleware Status in Python client library for Keystone: Fix Released Bug description: The juno->kilo upgrade tests fails during the installation of keystonemiddleware with a version conflict exception: 2015-06-29 17:18:03.056 | + /usr/local/bin/keystone-manage db_sync 2015-06-29 17:18:03.285 | Traceback (most recent call last): 2015-06-29 17:18:03.285 | File "/usr/local/bin/keystone-manage", line 4, in 2015-06-29 17:18:03.285 | __import__('pkg_resources').require('keystone==2015.1.1.dev13') 2015-06-29 17:18:03.285 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3084, in 2015-06-29 17:18:03.286 | @_call_aside 2015-06-29 17:18:03.286 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3070, in _call_aside 2015-06-29 17:18:03.286 | f(*args, **kwargs) 2015-06-29 17:18:03.286 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3097, in _initialize_master_working_set 2015-06-29 17:18:03.287 | working_set = WorkingSet._build_master() 2015-06-29 17:18:03.287 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 653, in _build_master 2015-06-29 17:18:03.287 | return cls._build_from_requirements(__requires__) 2015-06-29 17:18:03.287 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 666, in _build_from_requirements 2015-06-29 17:18:03.287 | dists = ws.resolve(reqs, Environment()) 2015-06-29 17:18:03.287 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 844, in resolve 2015-06-29 17:18:03.287 | raise VersionConflict(dist, req).with_context(dependent_req) 2015-06-29 17:18:03.287 | pkg_resources.ContextualVersionConflict: (oslo.serialization 1.4.0 (/usr/local/lib/python2.7/dist-packages), Requirement.parse('oslo.serialization<=1.2.0,>=1.0.0'), set(['python-keystoneclient'])) 2015-06-29 17:18:03.297 | + die 61 'DB sync error' 2015-06-29 17:18:03.297 | + local exitcode=1 See for example: https://review.openstack.org/#/c/195657/ http://logs.openstack.org/57/195657/1/gate/gate-grenade-dsvm/0443321/logs/grenade.sh.txt.gz Maybe it's a version issue in some keystone module, or maybe grenade does not upgrade the dependencies in the proper order. This error (currently masked by another set of failures which involve log storing on the gates) blocks the backport of patches to kilo at least for horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1470108/+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 1470234] [NEW] test_arp_spoof_allowed_address_pairs_0cidr sporadically failing functional job
Public bug reported: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidGVzdF9hcnBfc3Bvb2ZfYWxsb3dlZF9hZGRyZXNzX3BhaXJzXzBjaWRyXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MzU2OTU1NTk3MTB9 18 hits in last 7 days. Here's a failure trace of test_arp_spoof_allowed_address_pairs_0cidr(native): ft1.78: neutron.tests.functional.agent.test_ovs_flows.ARPSpoofOFCtlTestCase.test_arp_spoof_allowed_address_pairs_0cidr(native)_StringException: Empty attachments: pythonlogging:'neutron.api.extensions' stderr stdout pythonlogging:'': {{{ 2015-06-30 19:36:25,695ERROR [neutron.agent.linux.utils] Command: ['ip', 'netns', 'exec', 'func-8f787d60-208d-4524-b4d4-e79b5cd19eae', 'ping', '-c', 1, '-W', 1, '192.168.0.2'] Exit code: 1 Stdin: Stdout: PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. --- 192.168.0.2 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms Stderr: }}} Traceback (most recent call last): File "neutron/tests/functional/agent/test_ovs_flows.py", line 169, in test_arp_spoof_allowed_address_pairs_0cidr net_helpers.assert_ping(self.src_namespace, self.dst_addr) File "neutron/tests/common/net_helpers.py", line 69, in assert_ping dst_ip]) File "neutron/agent/linux/ip_lib.py", line 676, in execute extra_ok_codes=extra_ok_codes, **kwargs) File "neutron/agent/linux/utils.py", line 138, in execute raise RuntimeError(m) RuntimeError: Command: ['ip', 'netns', 'exec', 'func-8f787d60-208d-4524-b4d4-e79b5cd19eae', 'ping', '-c', 1, '-W', 1, '192.168.0.2'] Exit code: 1 Stdin: Stdout: PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. --- 192.168.0.2 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms ** Affects: neutron Importance: High Status: New ** Tags: functional-tests ** Changed in: neutron Importance: Medium => High ** Description changed: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidGVzdF9hcnBfc3Bvb2ZfYWxsb3dlZF9hZGRyZXNzX3BhaXJzXzBjaWRyXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MzU2OTU1NTk3MTB9 18 hits in last 7 days. + + Here's a failure trace of + test_arp_spoof_allowed_address_pairs_0cidr(native): + + ft1.78: neutron.tests.functional.agent.test_ovs_flows.ARPSpoofOFCtlTestCase.test_arp_spoof_allowed_address_pairs_0cidr(native)_StringException: Empty attachments: + pythonlogging:'neutron.api.extensions' + stderr + stdout + + pythonlogging:'': {{{ + 2015-06-30 19:36:25,695ERROR [neutron.agent.linux.utils] + Command: ['ip', 'netns', 'exec', 'func-8f787d60-208d-4524-b4d4-e79b5cd19eae', 'ping', '-c', 1, '-W', 1, '192.168.0.2'] + Exit code: 1 + Stdin: + Stdout: PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. + + --- 192.168.0.2 ping statistics --- + 1 packets transmitted, 0 received, 100% packet loss, time 0ms + + + Stderr: + }}} + + Traceback (most recent call last): + File "neutron/tests/functional/agent/test_ovs_flows.py", line 169, in test_arp_spoof_allowed_address_pairs_0cidr + net_helpers.assert_ping(self.src_namespace, self.dst_addr) + File "neutron/tests/common/net_helpers.py", line 69, in assert_ping + dst_ip]) + File "neutron/agent/linux/ip_lib.py", line 676, in execute + extra_ok_codes=extra_ok_codes, **kwargs) + File "neutron/agent/linux/utils.py", line 138, in execute + raise RuntimeError(m) + RuntimeError: + Command: ['ip', 'netns', 'exec', 'func-8f787d60-208d-4524-b4d4-e79b5cd19eae', 'ping', '-c', 1, '-W', 1, '192.168.0.2'] + Exit code: 1 + Stdin: + Stdout: PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. + + --- 192.168.0.2 ping statistics --- + 1 packets transmitted, 0 received, 100% packet loss, time 0ms -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1470234 Title: test_arp_spoof_allowed_address_pairs_0cidr sporadically failing functional job Status in OpenStack Neutron (virtual network service): New Bug description: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwidGVzdF9hcnBfc3Bvb2ZfYWxsb3dlZF9hZGRyZXNzX3BhaXJzXzBjaWRyXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MzU2OTU1NTk3MTB9 18 hits in last 7 days. Here's a failure trace of test_arp_spoof_allowed_address_pairs_0cidr(native): ft1.78: neutron.tests.functional.agent.test_ovs_flows.ARPSpoofOFCtlTestCase.test_arp_spoof_allowed_address_pairs_0cidr(native)_StringException: Empty attachments: pythonlogging:'neutron.api.extensions' stderr stdout pythonlogging:'': {{{ 2015-06-30 19:36:25,695ERROR [neutr
[Yahoo-eng-team] [Bug 1470225] [NEW] Support deprecated image types
Public bug reported: I frequently update the base Trusty images available to my users. After I do that, I want to discourage them from creating new servers based on the old images. If I remove the old images entirely or make them private, Horizon shows servers as having type 'unknown.' I'd like Horizon to support a glance property of 'deprecated' for an image that should remain visible in Horizon but not be added to the image pulldown when an instance is created. ** 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/1470225 Title: Support deprecated image types Status in OpenStack Dashboard (Horizon): New Bug description: I frequently update the base Trusty images available to my users. After I do that, I want to discourage them from creating new servers based on the old images. If I remove the old images entirely or make them private, Horizon shows servers as having type 'unknown.' I'd like Horizon to support a glance property of 'deprecated' for an image that should remain visible in Horizon but not be added to the image pulldown when an instance is created. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1470225/+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 1470219] [NEW] "nova show" does not return block device mapping
Public bug reported: Using nova/stable/icehouse A "nova show instance_id" command as well as "nova.servers.get(instance_id)" with the Python API does not show the block device mapping information for the instance. This would be useful for boot from volume instances to check attributes such as "delete_on_termination", or see which volume attached to an instance is its root volume. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1470219 Title: "nova show" does not return block device mapping Status in OpenStack Compute (Nova): New Bug description: Using nova/stable/icehouse A "nova show instance_id" command as well as "nova.servers.get(instance_id)" with the Python API does not show the block device mapping information for the instance. This would be useful for boot from volume instances to check attributes such as "delete_on_termination", or see which volume attached to an instance is its root volume. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1470219/+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 1470205] [NEW] Keystone IdP SAML metadata insufficient for websso flow
Public bug reported: The metadata generated by Keystone IdP includes a binding of type URI. From https://github.com/openstack/keystone/blame/8bb63620b4d9ec71b0a60ed705938103d7d3c2c2/keystone/contrib/federation/idp.py#L490: def single_sign_on_service(): idp_sso_endpoint = CONF.saml.idp_sso_endpoint return md.SingleSignOnService( binding=saml2.BINDING_URI, location=idp_sso_endpoint) Looking at the Shibboleth SessionInitiator code, this is not a valid binding for a default websso configuration. The accepted bindings are defined at https://github.com/craigpg/shibboleth- sp2/blob/f62a7996e195a9c026f3f8cb0e9086594b7f8515/shibsp/handler/impl/SAML2SessionInitiator.cpp#L164-L165: // No override, so we'll install a default binding precedence. string prec = string(samlconstants::SAML20_BINDING_HTTP_REDIRECT) + ' ' + samlconstants::SAML20_BINDING_HTTP_POST + ' ' + samlconstants::SAML20_BINDING_HTTP_POST_SIMPLESIGN + ' ' + samlconstants::SAML20_BINDING_HTTP_ARTIFACT; ** Affects: keystone Importance: Wishlist Assignee: Marek Denis (marek-denis) 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/1470205 Title: Keystone IdP SAML metadata insufficient for websso flow Status in OpenStack Identity (Keystone): New Bug description: The metadata generated by Keystone IdP includes a binding of type URI. From https://github.com/openstack/keystone/blame/8bb63620b4d9ec71b0a60ed705938103d7d3c2c2/keystone/contrib/federation/idp.py#L490: def single_sign_on_service(): idp_sso_endpoint = CONF.saml.idp_sso_endpoint return md.SingleSignOnService( binding=saml2.BINDING_URI, location=idp_sso_endpoint) Looking at the Shibboleth SessionInitiator code, this is not a valid binding for a default websso configuration. The accepted bindings are defined at https://github.com/craigpg/shibboleth- sp2/blob/f62a7996e195a9c026f3f8cb0e9086594b7f8515/shibsp/handler/impl/SAML2SessionInitiator.cpp#L164-L165: // No override, so we'll install a default binding precedence. string prec = string(samlconstants::SAML20_BINDING_HTTP_REDIRECT) + ' ' + samlconstants::SAML20_BINDING_HTTP_POST + ' ' + samlconstants::SAML20_BINDING_HTTP_POST_SIMPLESIGN + ' ' + samlconstants::SAML20_BINDING_HTTP_ARTIFACT; To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1470205/+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 1470192] [NEW] '501 Not Implemented' responce while send HTTP request with custom method
Public bug reported: Steps to reproduce: 1. Send request something like this: ANY-CUSTOM-METHOD /v2/images HTTP/1.1 Host: localhost:2081 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 X-auth-token: fc6fa22976da45b2af76622935825625 Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Expected result: HTTP/1.1 HTTP 400 - Bad Request Actual result: HTTP/1.1 501 Not Implemented Content-Length: 216 Content-Type: text/html; charset=UTF-8 X-Openstack-Request-Id: req-req-0deadf35-4b66-471b-bb91-ce88344f898c Date: Tue, 30 Jun 2015 17:47:52 GMT Connection: keep-alive 501 Not Implemented 501 Not Implemented The server has either erred or is incapable of performing the requested operation. ** Affects: glance Importance: Undecided Status: New ** Tags: glance -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1470192 Title: '501 Not Implemented' responce while send HTTP request with custom method Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Steps to reproduce: 1. Send request something like this: ANY-CUSTOM-METHOD /v2/images HTTP/1.1 Host: localhost:2081 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 X-auth-token: fc6fa22976da45b2af76622935825625 Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Expected result: HTTP/1.1 HTTP 400 - Bad Request Actual result: HTTP/1.1 501 Not Implemented Content-Length: 216 Content-Type: text/html; charset=UTF-8 X-Openstack-Request-Id: req-req-0deadf35-4b66-471b-bb91-ce88344f898c Date: Tue, 30 Jun 2015 17:47:52 GMT Connection: keep-alive 501 Not Implemented 501 Not Implemented The server has either erred or is incapable of performing the requested operation. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1470192/+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 1470186] [NEW] Pylint 1.4.1 broken due to new logilab.common 1.0.0 release
Public bug reported: Pylint 1.4.1 is using logilab-common, which had a release on the 30th, breaking pylint. Pylint developers are planning a logilab common release tomorrow which should unbreak pylint once again, at which point I'll re- enable pylint. ** Affects: neutron Importance: Critical Assignee: Assaf Muller (amuller) Status: Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1470186 Title: Pylint 1.4.1 broken due to new logilab.common 1.0.0 release Status in OpenStack Neutron (virtual network service): Confirmed Bug description: Pylint 1.4.1 is using logilab-common, which had a release on the 30th, breaking pylint. Pylint developers are planning a logilab common release tomorrow which should unbreak pylint once again, at which point I'll re-enable pylint. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1470186/+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 1470179] [NEW] Instance metadata should include project_id
Public bug reported: As per https://www.mail- archive.com/search?l=openst...@lists.openstack.org&q=subject:%22Re\%3A+\[Openstack\]+How+should+an+instance+learn+what+tenant+it+is+in\%3F%22&o=newest It's weirdly hard for an instance to learn what project it's in. Let's just add project_id to instance metadata. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1470179 Title: Instance metadata should include project_id Status in OpenStack Compute (Nova): New Bug description: As per https://www.mail- archive.com/search?l=openst...@lists.openstack.org&q=subject:%22Re\%3A+\[Openstack\]+How+should+an+instance+learn+what+tenant+it+is+in\%3F%22&o=newest It's weirdly hard for an instance to learn what project it's in. Let's just add project_id to instance metadata. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1470179/+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 1470164] [NEW] Glance v1 not working with "allow_anonymous_access = True"
Public bug reported: Steps to reproduce: 1. Stop "glance-api" service. 2. In "glance-api.conf" set "allow_anonymous_access = True" 3. Start "glance-api" service. 4. Trying to get image-list with use v1 and without keystone "x-auth-token" GET /v1/images HTTP/1.1 Host: 172.18.85.25:2081 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Actual result: HTTP/1.1 500 Internal Server Error Content-Type: text/plain Content-Length: 0 Date: Tue, 30 Jun 2015 14:54:42 GMT Connection: close ** Affects: glance Importance: Undecided Status: New ** Tags: glance ** Attachment added: "Glance-api log with traceback" https://bugs.launchpad.net/bugs/1470164/+attachment/4422528/+files/glance-api.log -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1470164 Title: Glance v1 not working with "allow_anonymous_access = True" Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Steps to reproduce: 1. Stop "glance-api" service. 2. In "glance-api.conf" set "allow_anonymous_access = True" 3. Start "glance-api" service. 4. Trying to get image-list with use v1 and without keystone "x-auth-token" GET /v1/images HTTP/1.1 Host: 172.18.85.25:2081 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Actual result: HTTP/1.1 500 Internal Server Error Content-Type: text/plain Content-Length: 0 Date: Tue, 30 Jun 2015 14:54:42 GMT Connection: close To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1470164/+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 1470154] [NEW] List objects should use obj_relationships
Public bug reported: Nova's List-based objects have something called child_versions, which is a naive mapping of the objects field and the version relationships between the list object and the content object. This was created before we generalized the work in obj_relationships, which normal objects now use. The list-based objects still use child_versions, which means we need a separate test and separate developer behaviors when updating these. For consistency, we should replace child_versions on all the list objects with obj_relationships, remove the list-specific test in test_objects.py, and make sure that the generalized tests properly cover list objects and relationships between list and non-list objects. ** Affects: nova Importance: Low Assignee: Ryan Rossiter (rlrossit) Status: Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1470154 Title: List objects should use obj_relationships Status in OpenStack Compute (Nova): Confirmed Bug description: Nova's List-based objects have something called child_versions, which is a naive mapping of the objects field and the version relationships between the list object and the content object. This was created before we generalized the work in obj_relationships, which normal objects now use. The list-based objects still use child_versions, which means we need a separate test and separate developer behaviors when updating these. For consistency, we should replace child_versions on all the list objects with obj_relationships, remove the list-specific test in test_objects.py, and make sure that the generalized tests properly cover list objects and relationships between list and non-list objects. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1470154/+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 1470153] [NEW] Nova object relationships ignore List objects
Public bug reported: In nova/tests/objects/test_objects.py, we have an important test called test_relationships(). This ensures that we have version mappings between objects that depend on each other, and that those versions and relationships are bumped when one object changes versions. That test currently excludes any objects that are based on the List mixin, which obscures dependencies that do things like Foo->BarList->Bar. The test needs to be modified to not exclude List-based objects, and the relationship map needs to be updated for the List objects that are currently excluded. ** Affects: nova Importance: Low Assignee: Ryan Rossiter (rlrossit) Status: Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1470153 Title: Nova object relationships ignore List objects Status in OpenStack Compute (Nova): Confirmed Bug description: In nova/tests/objects/test_objects.py, we have an important test called test_relationships(). This ensures that we have version mappings between objects that depend on each other, and that those versions and relationships are bumped when one object changes versions. That test currently excludes any objects that are based on the List mixin, which obscures dependencies that do things like Foo->BarList->Bar. The test needs to be modified to not exclude List-based objects, and the relationship map needs to be updated for the List objects that are currently excluded. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1470153/+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 1470142] [NEW] LuksEncryptor attach volume fails for NFS
Public bug reported: Tempest scenario TestEncryptedCinderVolumes has been silently skipped when run with NFS cinder drivers that did not set the 'encrypted' key in the connection_info['data'] dict in their initialize_connection methods. Change https://review.openstack.org/#/c/193673/ - which sets the encrypted flag generically, in the VolumeManager's initialize_connection, on the basis of the volume.encryption_key_id value - causes this test to actually run its encryption providers and exposes a problem in LuksEncryptor:attach_volume() for NFS exported volumes. At https://github.com/openstack/nova/blob/master/nova/volume/encryptors/luks.py#L119 we have: # modify the original symbolic link to refer to the decrypted device utils.execute('ln', '--symbolic', '--force', '/dev/mapper/%s' % self.dev_name, self.symlink_path, run_as_root=True, check_exit_code=True) but in TestEncryptedCinderVolumes we get the following exception: 2015-06-29 06:44:06.353 DEBUG oslo_concurrency.processutils [req-35a458fe-8bfc-4570-ac8e-388e8b74d4ea TestEncryptedCinderVolumes-1523565967 TestEncryptedCinderVolumes-1577400956] u'sudo nova-rootwrap /etc/nova/rootwrap.conf ln --symbolic --force /dev/mapper/volume-f5684ecc-959f-4de8-8d62-a8adf4bdb4cc /opt/stack/data/nova/mnt/21dd48babac42ae884d1192b8697a041/volume-f5684ecc-959f-4de8-8d62-a8adf4bdb4cc' failed. Not Retrying. execute /usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:293 2015-06-29 06:44:06.353 ERROR nova.virt.libvirt.driver [req-35a458fe-8bfc-4570-ac8e-388e8b74d4ea TestEncryptedCinderVolumes-1523565967 TestEncryptedCinderVolumes-1577400956] [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] Failed to attach volume at mountpoint: /dev/vdb 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] Traceback (most recent call last): 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 1082, in attach_volume 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] encryptor.attach_volume(context, **encryption) 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] File "/opt/stack/new/nova/nova/volume/encryptors/luks.py", line 121, in attach_volume 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] run_as_root=True, check_exit_code=True) 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] File "/opt/stack/new/nova/nova/utils.py", line 229, in execute 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] return processutils.execute(*cmd, **kwargs) 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] File "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 260, in execute 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] cmd=sanitized_cmd) 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] ProcessExecutionError: Unexpected error while running command. 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] Command: sudo nova-rootwrap /etc/nova/rootwrap.conf ln --symbolic --force /dev/mapper/volume-f5684ecc-959f-4de8-8d62-a8adf4bdb4cc /opt/stack/data/nova/mnt/21dd48babac42ae884d1192b8697a041/volume-f5684ecc-959f-4de8-8d62-a8adf4bdb4cc 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] Exit code: 99 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] Stdout: u'' 2015-06-29 06:44:06.353 13140 ERROR nova.virt.libvirt.driver [instance: b285fed7-6d65-4b57-9ab0-8c17ce0cf6a8] Stderr: u'/usr/local/bin/nova-rootwrap: Unauthorized command: ln --symbolic --force /dev/mapper/volume-f5684ecc-959f-4de8-8d62-a8adf4bdb4cc /opt/stack/data/nova/mnt/21dd48babac42ae884d1192b8697a041/volume-f5684ecc-959f-4de8-8d62-a8adf4bdb4cc (no filter matched)\n' The cause is evidently the rootwrap filter at https://github.com/openstack/nova/blob/master/etc/nova/rootwrap.d/compute.filters#L215, namely: ln: RegExpFilter, ln, root, ln, --symbolic, --force, /dev/mapper/ip -.*-iscsi-iqn.*, /dev/disk/by-path/ip-.*-iscsi-iqn.* which only allows for iscsi paths. ** Affects: nova Importance: Undecided Status: New ** Tags: rootwrap -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed
[Yahoo-eng-team] [Bug 1470094] Re: live migration on ML2 Mechanism Event
Launchpad bugs are not the place for developer questions. Please hop on #openstack-neutron on Freenode. ** 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/1470094 Title: live migration on ML2 Mechanism Event Status in OpenStack Neutron (virtual network service): Invalid Bug description: Hi, ML2 driver: A mechanism driver is called on the creation, update, and deletion of networks and ports. For every event, there are two methods that get called - one within the database transaction (method suffix of _precommit), one right afterwards (method suffix of _postcommit) When live migrationon TestVM4 on Openstack, I can't see any event(create_port_precommit, create_port_postcommit). I only see update_port_precommit and update_port_postcommit. I have question: How to do implement ML2 plugin? 2015-06-30 18:25:40.627 2807 DEBUG neutron.plugins.ml2.rpc [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Device 59571389-024f-4475-b7f5-1156dadd7e4e details requested by agent ovs-agent-TestVM4 with host TestVM4 get_device_details /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/rpc.py:60 2015-06-30 18:25:40.644 2807 DEBUG neutron.plugins.ml2.rpc [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Returning: {'profile': {}, 'admin_state_up': True, 'network_id': u'61eefda2-97df-4e5c-a844-a6aad001e5d9', 'segmentation_id': 1501L, 'device_owner': u'compute:nova', 'physical_network': u'physnet1', 'mac_address': u'fa:16:3e:f6:d1:a4', 'device': u'59571389-024f-4475-b7f5-1156dadd7e4e', 'port_id': u'59571389-024f-4475-b7f5-1156dadd7e4e', 'fixed_ips': [{'subnet_id': u'db6690d1-dbe9-479c-b0dd-14c1ea5d2d43', 'ip_address': u'10.1.1.101'}], 'network_type': u'vlan'} get_device_details /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/rpc.py:105 2015-06-30 18:25:40.797 2807 DEBUG neutron.context [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Arguments dropped when creating context: {u'project_name': None, u'tenant': None} __init__ /usr/lib/python2.7/dist-packages/neutron/context.py:83 2015-06-30 18:25:40.797 2807 DEBUG neutron.plugins.ml2.rpc [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Device 59571389-024f-4475-b7f5-1156dadd7e4e up at agent ovs-agent-TestVM4 update_device_up /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/rpc.py:155 2015-06-30 18:25:40.815 2807 DEBUG neutron.openstack.common.lockutils [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Got semaphore "db-access" lock /usr/lib/python2.7/dist-packages/neutron/openstack/common/lockutils.py:168 2015-06-30 18:25:40.834 2807 INFO neutron.plugins.ml2.drivers.xxx.mechanism_xxx [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] xxx ML2 driver: update_port_precommit 2015-06-30 18:25:40.838 2807 INFO neutron.plugins.ml2.drivers.xxx.mechanism_xxx [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] xxx ML2 driver: update_port_postcommit 2015-06-30 18:25:40.967 2807 DEBUG neutron.context [req-83e77512-6a29-47c7-825b-4cca5b94d823 None] Arguments dropped when creating context: {u'project_name': None, u'tenant': None} __init__ /usr/lib/python2.7/dist-packages/neutron/context.py:83 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1470094/+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 1338844] Re: "FixedIpLimitExceeded: Maximum number of fixed ips exceeded" in tempest nova-network runs since 7/4
Brad, thank you for the response! It looks like this bug hasn't been seen by anyone a long time. Moving the bug status back to "Fix released". Feel free to reopen the bug and set the status back to ''Confirmed'' if you encounter the issue. ** Changed in: tempest Status: Confirmed => 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/1338844 Title: "FixedIpLimitExceeded: Maximum number of fixed ips exceeded" in tempest nova-network runs since 7/4 Status in OpenStack Compute (Nova): Invalid Status in Tempest: Fix Released Bug description: http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiQnVpbGRBYm9ydEV4Y2VwdGlvbjogQnVpbGQgb2YgaW5zdGFuY2VcIiBBTkQgbWVzc2FnZTpcImFib3J0ZWQ6IEZhaWxlZCB0byBhbGxvY2F0ZSB0aGUgbmV0d29yayhzKSB3aXRoIGVycm9yIE1heGltdW0gbnVtYmVyIG9mIGZpeGVkIGlwcyBleGNlZWRlZCwgbm90IHJlc2NoZWR1bGluZy5cIiBBTkQgdGFnczpcInNjcmVlbi1uLWNwdS50eHRcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQwNDc3OTE1MzY1MiwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ== Saw it here: http://logs.openstack.org/63/98563/5/check/check-tempest-dsvm- postgres-full/1472e7b/logs/screen-n-cpu.txt.gz?level=TRACE Looks like it's only in jobs using nova-network. Started on 7/4, 70 failures in 7 days, check and gate, multiple changes. Maybe related to https://review.openstack.org/104581. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1338844/+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 1343613] Re: Deadlock found when trying to get lock; try restarting transaction
It looks like this issue is not related to Tempest. As Matthew said, tempest runs just triggered it. So moving the bug status to "Invalid". ** Changed in: tempest Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1343613 Title: Deadlock found when trying to get lock; try restarting transaction Status in OpenStack Compute (Nova): Fix Released Status in Tempest: Invalid Bug description: Example URL: http://logs.openstack.org/31/107131/1/gate/gate-grenade-dsvm/d019d8e/logs/old/screen-n-api.txt.gz?level=ERROR#_2014-07-17_20_59_37_031 Logstash query(?): message:"Deadlock found when trying to get lock; try restarting transaction" AND loglevel:"ERROR" AND build_status:"FAILURE" 32 hits in 48 hours. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1343613/+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 1470108] [NEW] Gate upgrade test juno->kilo fails on oslo.serialization dependency mismatch for keystonemiddleware
Public bug reported: The juno->kilo upgrade tests fails during the installation of keystonemiddleware with a version conflict exception: 2015-06-29 17:18:03.056 | + /usr/local/bin/keystone-manage db_sync 2015-06-29 17:18:03.285 | Traceback (most recent call last): 2015-06-29 17:18:03.285 | File "/usr/local/bin/keystone-manage", line 4, in 2015-06-29 17:18:03.285 | __import__('pkg_resources').require('keystone==2015.1.1.dev13') 2015-06-29 17:18:03.285 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3084, in 2015-06-29 17:18:03.286 | @_call_aside 2015-06-29 17:18:03.286 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3070, in _call_aside 2015-06-29 17:18:03.286 | f(*args, **kwargs) 2015-06-29 17:18:03.286 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3097, in _initialize_master_working_set 2015-06-29 17:18:03.287 | working_set = WorkingSet._build_master() 2015-06-29 17:18:03.287 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 653, in _build_master 2015-06-29 17:18:03.287 | return cls._build_from_requirements(__requires__) 2015-06-29 17:18:03.287 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 666, in _build_from_requirements 2015-06-29 17:18:03.287 | dists = ws.resolve(reqs, Environment()) 2015-06-29 17:18:03.287 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 844, in resolve 2015-06-29 17:18:03.287 | raise VersionConflict(dist, req).with_context(dependent_req) 2015-06-29 17:18:03.287 | pkg_resources.ContextualVersionConflict: (oslo.serialization 1.4.0 (/usr/local/lib/python2.7/dist-packages), Requirement.parse('oslo.serialization<=1.2.0,>=1.0.0'), set(['python-keystoneclient'])) 2015-06-29 17:18:03.297 | + die 61 'DB sync error' 2015-06-29 17:18:03.297 | + local exitcode=1 See for example: https://review.openstack.org/#/c/195657/ http://logs.openstack.org/57/195657/1/gate/gate-grenade-dsvm/0443321/logs/grenade.sh.txt.gz Maybe it's a version issue in some keystone module, or maybe grenade does not upgrade the dependencies in the proper order. This error (currently masked by another set of failures which involve log storing on the gates) blocks the backport of patches to kilo at least for horizon. ** Affects: grenade Importance: Undecided Status: New ** Affects: horizon Importance: Undecided Status: New ** Also 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/1470108 Title: Gate upgrade test juno->kilo fails on oslo.serialization dependency mismatch for keystonemiddleware Status in Grenade - OpenStack upgrade testing: New Status in OpenStack Dashboard (Horizon): New Bug description: The juno->kilo upgrade tests fails during the installation of keystonemiddleware with a version conflict exception: 2015-06-29 17:18:03.056 | + /usr/local/bin/keystone-manage db_sync 2015-06-29 17:18:03.285 | Traceback (most recent call last): 2015-06-29 17:18:03.285 | File "/usr/local/bin/keystone-manage", line 4, in 2015-06-29 17:18:03.285 | __import__('pkg_resources').require('keystone==2015.1.1.dev13') 2015-06-29 17:18:03.285 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3084, in 2015-06-29 17:18:03.286 | @_call_aside 2015-06-29 17:18:03.286 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3070, in _call_aside 2015-06-29 17:18:03.286 | f(*args, **kwargs) 2015-06-29 17:18:03.286 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3097, in _initialize_master_working_set 2015-06-29 17:18:03.287 | working_set = WorkingSet._build_master() 2015-06-29 17:18:03.287 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 653, in _build_master 2015-06-29 17:18:03.287 | return cls._build_from_requirements(__requires__) 2015-06-29 17:18:03.287 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 666, in _build_from_requirements 2015-06-29 17:18:03.287 | dists = ws.resolve(reqs, Environment()) 2015-06-29 17:18:03.287 | File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 844, in resolve 2015-06-29 17:18:03.287 | raise VersionConflict(dist, req).with_context(dependent_req) 2015-06-29 17:18:03.287 | pkg_resources.ContextualVersionConflict: (oslo.serialization 1.4.0 (/usr/local/lib/python2.7/dist-packages), Requirement.parse('oslo.serialization<=1.2.0,>=1.0.0'), set(['python-keystoneclient'])) 2015-06-29 17:18:03.297 | + die 61 'DB sync error' 2015-06-29 17:18:03.297 | + local exitcode=1
[Yahoo-eng-team] [Bug 1449544] Re: Neutron-LB Health monitor association mismatch in horizon and CLI
The bug is fixed in kilo version . ** Changed in: horizon Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1449544 Title: Neutron-LB Health monitor association mismatch in horizon and CLI Status in OpenStack Dashboard (Horizon): Invalid Bug description: When a new pool is created, all the health monitors that are available are shown in LB-Pool Information in Horizon Dashboard. But in CLI , neutron lb-pool-show shows no monitors associated to the newly created Pool. Please refer "LB_HM_default_assoc_UI" and "LB_HM_default_assoc_CLI". Using CLI , associate any health monitor to the Pool, correct information will be displayed in Horizon Dashboard and CLI. So only after creating new pool, Horizon Dashboard lists all the health monitors , which is wrong and this needs to be corrected. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1449544/+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 1353962] Re: Test job fails with FixedIpLimitExceeded with nova network
It looks like this bug has nothing to do with Tempest. So moving the status of the bug to "Invalid". ** Changed in: tempest Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1353962 Title: Test job fails with FixedIpLimitExceeded with nova network Status in OpenStack Compute (Nova): Confirmed Status in Tempest: Invalid Bug description: VM creation failed due to a `shortage` in fixed IP. The fixed range is /24, tempest normally does not keeps up more than ~8 VM. message: "FixedIpLimitExceeded" AND filename:"logs/screen-n-net.txt" http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOiBcIkZpeGVkSXBMaW1pdEV4Y2VlZGVkXCIgQU5EIGZpbGVuYW1lOlwibG9ncy9zY3JlZW4tbi1uZXQudHh0XCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDc0MTA0MzE3MTgsIm1vZGUiOiIiLCJhbmFseXplX2ZpZWxkIjoiIn0= http://logs.openstack.org/23/112523/1/check/check-tempest-dsvm- postgres- full/acac6d9/logs/screen-n-cpu.txt.gz#_2014-08-07_09_42_18_481 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1353962/+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 1470094] [NEW] live migration on ML2 Mechanism Event
Public bug reported: Hi, ML2 driver: A mechanism driver is called on the creation, update, and deletion of networks and ports. For every event, there are two methods that get called - one within the database transaction (method suffix of _precommit), one right afterwards (method suffix of _postcommit) When live migrationon TestVM4 on Openstack, I can't see any event(create_port_precommit, create_port_postcommit). I only see update_port_precommit and update_port_postcommit. I have question: How to do implement ML2 plugin? 2015-06-30 18:25:40.627 2807 DEBUG neutron.plugins.ml2.rpc [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Device 59571389-024f-4475-b7f5-1156dadd7e4e details requested by agent ovs-agent-TestVM4 with host TestVM4 get_device_details /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/rpc.py:60 2015-06-30 18:25:40.644 2807 DEBUG neutron.plugins.ml2.rpc [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Returning: {'profile': {}, 'admin_state_up': True, 'network_id': u'61eefda2-97df-4e5c-a844-a6aad001e5d9', 'segmentation_id': 1501L, 'device_owner': u'compute:nova', 'physical_network': u'physnet1', 'mac_address': u'fa:16:3e:f6:d1:a4', 'device': u'59571389-024f-4475-b7f5-1156dadd7e4e', 'port_id': u'59571389-024f-4475-b7f5-1156dadd7e4e', 'fixed_ips': [{'subnet_id': u'db6690d1-dbe9-479c-b0dd-14c1ea5d2d43', 'ip_address': u'10.1.1.101'}], 'network_type': u'vlan'} get_device_details /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/rpc.py:105 2015-06-30 18:25:40.797 2807 DEBUG neutron.context [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Arguments dropped when creating context: {u'project_name': None, u'tenant': None} __init__ /usr/lib/python2.7/dist-packages/neutron/context.py:83 2015-06-30 18:25:40.797 2807 DEBUG neutron.plugins.ml2.rpc [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Device 59571389-024f-4475-b7f5-1156dadd7e4e up at agent ovs-agent-TestVM4 update_device_up /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/rpc.py:155 2015-06-30 18:25:40.815 2807 DEBUG neutron.openstack.common.lockutils [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Got semaphore "db-access" lock /usr/lib/python2.7/dist-packages/neutron/openstack/common/lockutils.py:168 2015-06-30 18:25:40.834 2807 INFO neutron.plugins.ml2.drivers.xxx.mechanism_xxx [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] xxx ML2 driver: update_port_precommit 2015-06-30 18:25:40.838 2807 INFO neutron.plugins.ml2.drivers.xxx.mechanism_xxx [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] xxx ML2 driver: update_port_postcommit 2015-06-30 18:25:40.967 2807 DEBUG neutron.context [req-83e77512-6a29-47c7-825b-4cca5b94d823 None] Arguments dropped when creating context: {u'project_name': None, u'tenant': None} __init__ /usr/lib/python2.7/dist-packages/neutron/context.py:83 ** Affects: neutron Importance: Undecided Status: New ** Description changed: Hi, ML2 driver: A mechanism driver is called on the creation, update, and deletion of networks and ports. For every event, there are two methods that get called - one within the database transaction (method suffix of _precommit), one right afterwards (method suffix of _postcommit) - When live migrationon TestVM4 on Openstack, I can't see any enent(create_port_precommit, create_port_postcommit). + When live migrationon TestVM4 on Openstack, I can't see any event(create_port_precommit, create_port_postcommit). I only see update_port_precommit and update_port_postcommit. - I have question: How to do implmemt ML2 plugin? - + I have question: How to do implement ML2 plugin? 2015-06-30 18:25:40.627 2807 DEBUG neutron.plugins.ml2.rpc [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Device 59571389-024f-4475-b7f5-1156dadd7e4e details requested by agent ovs-agent-TestVM4 with host TestVM4 get_device_details /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/rpc.py:60 2015-06-30 18:25:40.644 2807 DEBUG neutron.plugins.ml2.rpc [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Returning: {'profile': {}, 'admin_state_up': True, 'network_id': u'61eefda2-97df-4e5c-a844-a6aad001e5d9', 'segmentation_id': 1501L, 'device_owner': u'compute:nova', 'physical_network': u'physnet1', 'mac_address': u'fa:16:3e:f6:d1:a4', 'device': u'59571389-024f-4475-b7f5-1156dadd7e4e', 'port_id': u'59571389-024f-4475-b7f5-1156dadd7e4e', 'fixed_ips': [{'subnet_id': u'db6690d1-dbe9-479c-b0dd-14c1ea5d2d43', 'ip_address': u'10.1.1.101'}], 'network_type': u'vlan'} get_device_details /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/rpc.py:105 2015-06-30 18:25:40.797 2807 DEBUG neutron.context [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Arguments dropped when creating context: {u'project_name': None, u'tenant': None} __init__ /usr/lib/python2.7/dist-packages/neutron/context.py:83 2015-06-30 18:25:40.797 2807 DEBUG neutron.plugins.ml2.rpc [req-56a57784-0451-4f7d-a0d6-c866e4934bfc None] Device 59571389-024f-4475-b7f5-1156dadd7e4e up at agent o
[Yahoo-eng-team] [Bug 1470093] [NEW] The function "_get_multipath_iqn" get iqn is not complete
Public bug reported: 1. As for SAN storage has not only one iqn. so, one multipath device will have not only one iqn. 2、the function as follow: def _get_multipath_iqn(self, multipath_device): entries = self._get_iscsi_devices() for entry in entries: entry_real_path = os.path.realpath("/dev/disk/by-path/%s" % entry) entry_multipath = self._get_multipath_device_name(entry_real_path) if entry_multipath == multipath_device: return entry.split("iscsi-")[1].split("-lun")[0] return None so, if the multipath_device match one device, will return. but return only one iqn. but the issue is the multipath_device will contain several single device. as following: [root@R4300G2-ctrl02 ~]# ll /dev/disk/by-path/ lrwxrwxrwx 1 root root 9 Jun 30 14:45 ip-172.12.1.1:3260-iscsi-iqn.2099-01.cn.com.zte:usp.spr-a0:c0:00:00:00:53-lun-1 -> ../../sds lrwxrwxrwx 1 root root 9 Jun 30 14:45 ip-172.12.2.1:3260-iscsi-iqn.2099-01.cn.com.zte:usp.spr-a0:c0:00:00:00:53-lun-1 -> ../../sdl lrwxrwxrwx 1 root root 9 Jun 30 14:45 ip-172.12.1.2:3260-iscsi-iqn.2099-01.cn.com.zte:usp.spr-4c:09:b4:00:00:00-lun-1 -> ../../sdo lrwxrwxrwx 1 root root 9 Jun 30 14:45 ip-172.12.2.2:3260-iscsi-iqn.2099-01.cn.com.zte:usp.spr-4c:09:b4:00:00:00-lun-1 -> ../../sdm so the device have two different iqns.(-iqn.2099-01.cn.com.zte:usp.spr-4c:09:b4:00:00:00, iqn.2099-01.cn.com.zte:usp.spr-a0:c0:00:00:00:53) ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1470093 Title: The function "_get_multipath_iqn" get iqn is not complete Status in OpenStack Compute (Nova): New Bug description: 1. As for SAN storage has not only one iqn. so, one multipath device will have not only one iqn. 2、the function as follow: def _get_multipath_iqn(self, multipath_device): entries = self._get_iscsi_devices() for entry in entries: entry_real_path = os.path.realpath("/dev/disk/by-path/%s" % entry) entry_multipath = self._get_multipath_device_name(entry_real_path) if entry_multipath == multipath_device: return entry.split("iscsi-")[1].split("-lun")[0] return None so, if the multipath_device match one device, will return. but return only one iqn. but the issue is the multipath_device will contain several single device. as following: [root@R4300G2-ctrl02 ~]# ll /dev/disk/by-path/ lrwxrwxrwx 1 root root 9 Jun 30 14:45 ip-172.12.1.1:3260-iscsi-iqn.2099-01.cn.com.zte:usp.spr-a0:c0:00:00:00:53-lun-1 -> ../../sds lrwxrwxrwx 1 root root 9 Jun 30 14:45 ip-172.12.2.1:3260-iscsi-iqn.2099-01.cn.com.zte:usp.spr-a0:c0:00:00:00:53-lun-1 -> ../../sdl lrwxrwxrwx 1 root root 9 Jun 30 14:45 ip-172.12.1.2:3260-iscsi-iqn.2099-01.cn.com.zte:usp.spr-4c:09:b4:00:00:00-lun-1 -> ../../sdo lrwxrwxrwx 1 root root 9 Jun 30 14:45 ip-172.12.2.2:3260-iscsi-iqn.2099-01.cn.com.zte:usp.spr-4c:09:b4:00:00:00-lun-1 -> ../../sdm so the device have two different iqns.(-iqn.2099-01.cn.com.zte:usp.spr-4c:09:b4:00:00:00, iqn.2099-01.cn.com.zte:usp.spr-a0:c0:00:00:00:53) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1470093/+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 1470087] [NEW] stop glance-api service will raise exception
Public bug reported: 1. In redhat system, run systemctl stop openstack-glance-api.service will stop glance API service . 2. after step 1, the glance api log as follow: 2015-06-18 08:58:47.538 11453 CRITICAL glance [-] OSError: [Errno 38] Function not implemented 2015-06-18 08:58:47.538 11453 TRACE glance Traceback (most recent call last): 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/bin/glance-api", line 10, in 2015-06-18 08:58:47.538 11453 TRACE glance sys.exit(main()) 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/glance/cmd/api.py", line 90, in main 2015-06-18 08:58:47.538 11453 TRACE glance server.wait() 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/glance/common/wsgi.py", line 406, in wait 2015-06-18 08:58:47.538 11453 TRACE glance self.wait_on_children() 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/glance/common/wsgi.py", line 345, in wait_on_children 2015-06-18 08:58:47.538 11453 TRACE glance pid, status = os.wait() 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/eventlet/green/os.py", line 78, in wait 2015-06-18 08:58:47.538 11453 TRACE glance return waitpid(0, 0) 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/eventlet/green/os.py", line 96, in waitpid 2015-06-18 08:58:47.538 11453 TRACE glance greenthread.sleep(0.01) 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/eventlet/greenthread.py", line 34, in sleep 2015-06-18 08:58:47.538 11453 TRACE glance hub.switch() 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 294, in switch 2015-06-18 08:58:47.538 11453 TRACE glance return self.greenlet.switch() 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 346, in run 2015-06-18 08:58:47.538 11453 TRACE glance self.wait(sleep_time) 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/eventlet/hubs/poll.py", line 82, in wait 2015-06-18 08:58:47.538 11453 TRACE glance sleep(seconds) 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/glance/common/wsgi.py", line 287, in kill_children 2015-06-18 08:58:47.538 11453 TRACE glance os.killpg(self.pgid, signal.SIGTERM) 2015-06-18 08:58:47.538 11453 TRACE glance OSError: [Errno 38] Function not implemented 2015-06-18 08:58:47.538 11453 TRACE glance 3.I use icehouse2014.1.3 version, but I review code in K version, this issue is also present ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1470087 Title: stop glance-api service will raise exception Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: 1. In redhat system, run systemctl stop openstack-glance-api.service will stop glance API service . 2. after step 1, the glance api log as follow: 2015-06-18 08:58:47.538 11453 CRITICAL glance [-] OSError: [Errno 38] Function not implemented 2015-06-18 08:58:47.538 11453 TRACE glance Traceback (most recent call last): 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/bin/glance-api", line 10, in 2015-06-18 08:58:47.538 11453 TRACE glance sys.exit(main()) 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/glance/cmd/api.py", line 90, in main 2015-06-18 08:58:47.538 11453 TRACE glance server.wait() 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/glance/common/wsgi.py", line 406, in wait 2015-06-18 08:58:47.538 11453 TRACE glance self.wait_on_children() 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/glance/common/wsgi.py", line 345, in wait_on_children 2015-06-18 08:58:47.538 11453 TRACE glance pid, status = os.wait() 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/eventlet/green/os.py", line 78, in wait 2015-06-18 08:58:47.538 11453 TRACE glance return waitpid(0, 0) 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/eventlet/green/os.py", line 96, in waitpid 2015-06-18 08:58:47.538 11453 TRACE glance greenthread.sleep(0.01) 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/eventlet/greenthread.py", line 34, in sleep 2015-06-18 08:58:47.538 11453 TRACE glance hub.switch() 2015-06-18 08:58:47.538 11453 TRACE glance File "/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 294, in switch 2015-06-18 08:58:47.538 11453 TRACE glance return self.greenlet.switch() 2015-06-18 08:58:4
[Yahoo-eng-team] [Bug 1469738] Re: The operation of create image has failed with not enough free quota storage although sufficient space was available
Actually, this is well described in the config option's documentation. As of today: cfg.StrOpt('user_storage_quota', default='0', help=_("Set a system wide quota for every user. This value is " "the total capacity that a user can use across " "all storage systems. A value of 0 means unlimited." "Optional unit can be specified for the value. Accepted " "units are B, KB, MB, GB and TB representing " "Bytes, KiloBytes, MegaBytes, GigaBytes and TeraBytes " "respectively. If no unit is specified then Bytes is " "assumed. Note that there should not be any space " "between value and unit and units are case sensitive.")), ** Changed in: glance Importance: Undecided => Low ** Changed in: glance 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/1469738 Title: The operation of create image has failed with not enough free quota storage although sufficient space was available Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Bug description: Description of problem: Creating an image has failed with error message:"Denying attempt to upload image because it exceeds the quota", although there was enough space for upload the image Version-Release number of selected component (if applicable): python-glanceclient-0.17.0-2.el7ost.noarch python-glance-2015.1.0-6.el7ost.noarch python-glance-store-0.4.0-1.el7ost.noarch openstack-glance-2015.1.0-6.el7ost.noarch How reproducible: 100% Steps to Reproduce: With only cirros image(size=12.6MB) run those steps 1. Edit /etc/glance/glance-api.conf set user_storage_quota =1536000 2. openstack-service restart glance 3. Try to upload an image less than 1536000MB Actual results: Failed with 'Denying attempt to upload image because it exceeds the quota' Expected results: Creating an image should succeed Additional info: It is similar to bug id=1043929 Glance logs To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1469738/+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 1470076] [NEW] Security Group Attributes that are documented as UUIDs require validation
Public bug reported: In the API, security_group_id and remote_group_id are documented as requiring UUIDs. ** Affects: neutron Importance: Undecided Assignee: Sean M. Collins (scollins) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1470076 Title: Security Group Attributes that are documented as UUIDs require validation Status in OpenStack Neutron (virtual network service): In Progress Bug description: In the API, security_group_id and remote_group_id are documented as requiring UUIDs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1470076/+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 1470052] [NEW] vm failed to start which image adaptertype type is scsi
Public bug reported: I followed by OpenStack Configuration reference[1], download the cloud image[2] and convert to vmdk: $ qemu-img convert -f qcow2 trusty-server-cloudimg-amd64-disk1.img -O vmdk ubuntu.vmdk and then use glance image-create command to upload image: $ glance image-create --name "ubuntu-thick-scsi" --is-public True --disk-format vmdk --container-format bare --property vmware_adaptertype="lsiLogic" \ --property vmware_disktype="preallocated" --property vmware_ostype="ubuntu64Guest" < ubuntu.vmdk +---+--+ | Property | Value| +---+--+ | Property 'vmware_adaptertype' | lsiLogic | | Property 'vmware_disktype'| preallocated | | Property 'vmware_ostype' | ubuntu64Guest| | checksum | 676e7fc58d2314db6a264c11804b2d4c | | container_format | bare | | created_at| 2015-06-26T23:55:36 | | deleted | False| | deleted_at| None | | disk_format | vmdk | | id| e79d4815-932b-4be6-b90c-0515f826c615 | | is_public | True | | min_disk | 0| | min_ram | 0| | name | ubuntu-thick-scsi| | owner | 93a022fd03d94b649d0127498e6149cf | | protected | False| | size | 852230144| | status| active | | updated_at| 2015-06-26T23:56:39 | | virtual_size | None | +---+--+ I created an instance in dashboard successful, But it failed to enter guest system. I doubt the instance does not have a controller to support scsi disk, when using ide , instance runs well. [1]http://docs.openstack.org/kilo/config-reference/content/vmware.html [2]http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img ** Affects: nova Importance: Undecided Status: New ** Tags: vmware -- 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/1470052 Title: vm failed to start which image adaptertype type is scsi Status in OpenStack Compute (Nova): New Bug description: I followed by OpenStack Configuration reference[1], download the cloud image[2] and convert to vmdk: $ qemu-img convert -f qcow2 trusty-server-cloudimg-amd64-disk1.img -O vmdk ubuntu.vmdk and then use glance image-create command to upload image: $ glance image-create --name "ubuntu-thick-scsi" --is-public True --disk-format vmdk --container-format bare --property vmware_adaptertype="lsiLogic" \ --property vmware_disktype="preallocated" --property vmware_ostype="ubuntu64Guest" < ubuntu.vmdk +---+--+ | Property | Value| +---+--+ | Property 'vmware_adaptertype' | lsiLogic | | Property 'vmware_disktype'| preallocated | | Property 'vmware_ostype' | ubuntu64Guest| | checksum | 676e7fc58d2314db6a264c11804b2d4c | | container_format | bare | | created_at| 2015-06-26T23:55:36 | | deleted | False| | deleted_at| None | | disk_format | vmdk | | id| e79d4815-932b-4be6-b90c-0515f826c615 | | is_public | True | | min_disk | 0| | min_ram | 0| | name | ubuntu-thick-scsi| | owner | 93a022fd03d94b649d0127498e6149cf | | protec
[Yahoo-eng-team] [Bug 1470051] [NEW] Make security-group-rule-create accept "any" protocol
Public bug reported: Related Bug: https://bugs.launchpad.net/python- neutronclient/+bug/1469642 When invalid protocol specified in security-group-rule-create, neutron server returns "protocol values [None, 'tcp', 'udp', 'icmp', 'icmpv6'] are supported" as below: % neutron security-group-rule-create --protocol foo bar Security group rule protocol foo not supported. Only protocol values [None, 'tcp', 'udp', 'icmp', 'icmpv6'] and integer representations [0 to 255] are supported. I think "None" to specify any protocols is confusing and inconsistent with FWaaS CLI options (it accepts "any" protocol). ** Affects: neutron Importance: Undecided Assignee: Masaki Matsushita (mmasaki) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1470051 Title: Make security-group-rule-create accept "any" protocol Status in OpenStack Neutron (virtual network service): In Progress Bug description: Related Bug: https://bugs.launchpad.net/python- neutronclient/+bug/1469642 When invalid protocol specified in security-group-rule-create, neutron server returns "protocol values [None, 'tcp', 'udp', 'icmp', 'icmpv6'] are supported" as below: % neutron security-group-rule-create --protocol foo bar Security group rule protocol foo not supported. Only protocol values [None, 'tcp', 'udp', 'icmp', 'icmpv6'] and integer representations [0 to 255] are supported. I think "None" to specify any protocols is confusing and inconsistent with FWaaS CLI options (it accepts "any" protocol). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1470051/+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 1470047] [NEW] CLI fails to report an error after creating a snapshot from instance
Public bug reported: Description of problem: The CLI fails to declare an error and stuck with "Server snapshotting... 0" when a user tries to save a snapshot of an instance while his quota is too small. Version-Release number of selected component (if applicable): python-glanceclient-0.17.0-2.el7ost.noarch python-glance-2015.1.0-6.el7ost.noarch python-glance-store-0.4.0-1.el7ost.noarch openstack-glance-2015.1.0-6.el7ost.noarch openstack-nova-api-2015.1.0-13.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. Edit /etc/glance/glance-api.conf set user_storage_quota with low space for creating snapshot from instance 2. openstack-service restart glance 3. Create a snapshot from instance via command line: 'nova image-create --poll' Actual results: The CLI fails to declare an error and stuck with "Server snapshotting... 0" Expected results: ERROR should be appeared indicating that quota is too small Additional info: log ** Affects: glance Importance: Undecided Status: New ** Attachment added: "Glance log" https://bugs.launchpad.net/bugs/1470047/+attachment/4422326/+files/api.log.tar.gz -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1470047 Title: CLI fails to report an error after creating a snapshot from instance Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Description of problem: The CLI fails to declare an error and stuck with "Server snapshotting... 0" when a user tries to save a snapshot of an instance while his quota is too small. Version-Release number of selected component (if applicable): python-glanceclient-0.17.0-2.el7ost.noarch python-glance-2015.1.0-6.el7ost.noarch python-glance-store-0.4.0-1.el7ost.noarch openstack-glance-2015.1.0-6.el7ost.noarch openstack-nova-api-2015.1.0-13.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. Edit /etc/glance/glance-api.conf set user_storage_quota with low space for creating snapshot from instance 2. openstack-service restart glance 3. Create a snapshot from instance via command line: 'nova image-create --poll' Actual results: The CLI fails to declare an error and stuck with "Server snapshotting... 0" Expected results: ERROR should be appeared indicating that quota is too small Additional info: log To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1470047/+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 1467927] Re: Odd number of vCPUs breaks 'prefer' threads policy
I was unsure how important the CPU topology exposed to the guest was, but you're correct in saying that using a best-effort prefer policy would result in bad scheduler decisions. We still have an 'implicit' separate policy for odd numbers of cores and an implicit 'prefer' policy for even numbers, but seeing as we don't really support thread policies yet then this isn't really a bug. I will close this bug and keep the above in mind when adding support for the thread policies. ** Changed in: nova Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1467927 Title: Odd number of vCPUs breaks 'prefer' threads policy Status in OpenStack Compute (Nova): Invalid Bug description: Using a CPU policy of dedicated ('hw:cpu_policy=dedicated') results in vCPUs being pinned to pCPUs, per the original blueprint: http://specs.openstack.org/openstack/nova- specs/specs/kilo/implemented/virt-driver-cpu-pinning.html When scheduling instance with this extra spec there appears to be an implicit use of the 'prefer' threads policy, i.e. where possible vCPUs are pinned to thread siblings first. This is "implicit" because the threads policy aspect of this spec has not yet been implemented. However, this implicit 'prefer' policy breaks when a VM with an odd number of vCPUs is booted. This has been seen on a Hyper-Threading- enabled host where "sibling sets" are two long, but it would presumably happen on any host where the number of siblings (or any number between this value and one) is not an factor of the number of vCPUs (i.e. vCPUs % n != 0, for siblings <= n > 0). It is reasonable to assume that a three vCPU VM, for example, should try best effort and use siblings for at the first two vCPUs of the VM (assuming you're on a host system with HyperThreading and sibling sets are of length two). This would give us a true best effort implementation. --- # Testing Configuration Testing was conducted on a single-node, Fedora 21-based (3.17.8-300.fc21.x86_64) OpenStack instance (built with devstack). The system is a dual-socket, 10 core, HT-enabled system (2 sockets * 10 cores * 2 threads = 40 "pCPUs". 0-9,20-29 = node0, 10-19,30-39 = node1). Two flavors were used: openstack flavor create --ram 4096 --disk 20 --vcpus 3 demo.odd nova flavor-key demo.odd set hw:cpu_policy=dedicated openstack flavor create --ram 4096 --disk 20 --vcpus 4 demo.even nova flavor-key demo.even set hw:cpu_policy=dedicated # Results Correct case ("even" number of vCPUs) = The output from 'virsh dumpxml [ID]' for the four vCPU VM is given below. Similar results can be seen for varying "even" numbers of vCPUs (2, 4, 10 tested): 4096 Incorrect case ("odd" number of vCPUs) == The output from 'virsh dumpxml [ID]' for the three vCPU VM is given below. Similar results can be seen for varying "odd" numbers of vCPUs (3, 5 tested): 3072 This isn't correct. We would expect something closer to this: 3072 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1467927/+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 1363558] Re: check the value of the configuration item retries
** Changed in: ceilometer Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1363558 Title: check the value of the configuration item retries Status in OpenStack Telemetry (Ceilometer): Invalid Status in OpenStack Compute (Nova): Fix Released Bug description: we need to to check the value of the configuration item block_device_retries in the code in order to ensure the "block_device_retries " equal or bigger than 1 , done like that the configuration item network_allocate_retries = In ceilometer, there are similar issues, there is no check for value of retries ceilometer.storage.mongo.utils.ConnectionPool#_mongo_connect and: ceilometer.ipmi.platform.intel_node_manager.NodeManager#init_node_manager To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1363558/+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 1469974] Re: kilo version swift doesn't work showing swiftclient:Authorrization Failure the resource could not be found
** Description changed: # swift --debug list DEBUG:keystoneclient.auth.identity.v2:Making authentication request to http://swift-test-keystone:35357/v3/tokens INFO:urllib3.connectionpool:Starting new HTTP connection (1): swift-test-keystone DEBUG:urllib3.connectionpool:"POST /v3/tokens HTTP/1.1" 404 93 DEBUG:keystoneclient.session:Request returned failure status: 404 ERROR:swiftclient:Authorization Failure. Authorization Failed: The resource could not be found. (HTTP 404) (Request-ID: req-93f815b5-7c3b-462e-b3c9-8c0ecf9f4da3) Traceback (most recent call last): - File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 1235, in _retry - self.url, self.token = self.get_auth() - File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 1209, in get_auth - insecure=self.insecure) - File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 406, in get_auth - auth_version=auth_version) - File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 341, in get_auth_keystone - raise ClientException('Authorization Failure. %s' % err) + File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 1235, in _retry + self.url, self.token = self.get_auth() + File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 1209, in get_auth + insecure=self.insecure) + File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 406, in get_auth + auth_version=auth_version) + File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 341, in get_auth_keystone + raise ClientException('Authorization Failure. %s' % err) ClientException: Authorization Failure. Authorization Failed: The resource could not be found. (HTTP 404) (Request-ID: req-93f815b5-7c3b-462e-b3c9-8c0ecf9f4da3) Authorization Failure. Authorization Failed: The resource could not be found. (HTTP 404) (Request-ID: req-93f815b5-7c3b-462e-b3c9-8c0ecf9f4da3) Setup of this environment is based on installation guide of kilo version. The openstack service on keystone node works just fine but swift doesn't. + + After then I modified the openstack client enviroment scripts from + export OS_AUTH_URL=http://controller:35357/v3 + to + export OS_AUTH_URL=http://controller:35357/v2.0 + + the debug info is as below + + DEBUG:keystoneclient.auth.identity.v2:Making authentication request to http://swift-test-keystone:35357/v2.0/tokens + INFO:urllib3.connectionpool:Starting new HTTP connection (1): swift-test-keystone + DEBUG:urllib3.connectionpool:"POST /v2.0/tokens HTTP/1.1" 200 1213 + DEBUG:iso8601.iso8601:Parsed 2015-06-30T08:21:48Z into {'tz_sign': None, 'second_fraction': None, 'hour': u'08', 'daydash': u'30', 'tz_hour': None, 'month': None, 'timezone': u'Z', 'second': u'48', 'tz_minute': None, 'year': u'2015', 'separator': u'T', 'monthdash': u'06', 'day': None, 'minute': u'21'} with default timezone + DEBUG:iso8601.iso8601:Got u'2015' for 'year' with default None + DEBUG:iso8601.iso8601:Got u'06' for 'monthdash' with default 1 + DEBUG:iso8601.iso8601:Got 6 for 'month' with default 6 + DEBUG:iso8601.iso8601:Got u'30' for 'daydash' with default 1 + DEBUG:iso8601.iso8601:Got 30 for 'day' with default 30 + DEBUG:iso8601.iso8601:Got u'08' for 'hour' with default None + DEBUG:iso8601.iso8601:Got u'21' for 'minute' with default None + DEBUG:iso8601.iso8601:Got u'48' for 'second' with default None + INFO:urllib3.connectionpool:Starting new HTTP connection (1): swift-test-proxynode1 + DEBUG:urllib3.connectionpool:"GET /v1/AUTH_c29f928f72f146fc9411e35c515c00a7?format=json HTTP/1.1" 401 131 + INFO:swiftclient:REQ: curl -i http://swift-test-proxynode1:8080/v1/AUTH_c29f928f72f146fc9411e35c515c00a7?format=json -X GET -H "X-Auth-Token: a09f170245314c3583c477ac36b5508b" + INFO:swiftclient:RESP STATUS: 401 Unauthorized + INFO:swiftclient:RESP HEADERS: [('content-length', '131'), ('connection', 'keep-alive'), ('x-trans-id', 'tx2c1fe6ed35674405a65c3-005592438c'), ('date', 'Tue, 30 Jun 2015 07:21:48 GMT'), ('content-type', 'text/html; charset=UTF-8'), ('www-authenticate', 'Swift realm="AUTH_c29f928f72f146fc9411e35c515c00a7"')] + INFO:swiftclient:RESP BODY: UnauthorizedThis server could not verify that you are authorized to access the document you requested. + DEBUG:keystoneclient.auth.identity.v2:Making authentication request to http://swift-test-keystone:35357/v2.0/tokens + INFO:urllib3.connectionpool:Starting new HTTP connection (1): swift-test-keystone + DEBUG:urllib3.connectionpool:"POST /v2.0/tokens HTTP/1.1" 200 1213 + DEBUG:iso8601.iso8601:Parsed 2015-06-30T08:21:49Z into {'tz_sign': None, 'second_fraction': None, 'hour': u'08', 'daydash': u'30', 'tz_hour': None, 'month': None, 'timezone': u'Z', 'second': u'49', 'tz_minute': None, 'year': u'2015', 'separator': u'T', 'monthdash': u'06', 'day': None, 'minute': u'21'} with default timezone + DEBUG:iso8601.iso8601:Got u'2015' for 'year' with default None + DEB