[Yahoo-eng-team] [Bug 1655710] [NEW] Query parameter validation using json schema - error messages
Public bug reported: A mechanism to validate query parameters using json schema was added in the following series: https://review.openstack.org/#/q/topic:bp/consistent-query- parameters-validation The resulting error messages aren't very user friendly though. For example, if you pass an invalid limit to os-keypairs list, you used to get a custom message rather than the obscure message generated by json schema. Before: webob.exc.HTTPBadRequest: Invalid input received: limit must be an integer After: nova.exception.ValidationError: Invalid input for query parameters 0. Value: abc. u'abc' does not match '^[0-9]*$' The exception raised also changed, which may be problematic for API consumers. We probably need another layer to transform these generated messages into something more user friendly, and perhaps consider raising HTTPBadRequest again with the nicer error message. ** Affects: nova Importance: Medium Status: Confirmed ** Tags: api -- 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/1655710 Title: Query parameter validation using json schema - error messages Status in OpenStack Compute (nova): Confirmed Bug description: A mechanism to validate query parameters using json schema was added in the following series: https://review.openstack.org/#/q/topic:bp/consistent-query- parameters-validation The resulting error messages aren't very user friendly though. For example, if you pass an invalid limit to os-keypairs list, you used to get a custom message rather than the obscure message generated by json schema. Before: webob.exc.HTTPBadRequest: Invalid input received: limit must be an integer After: nova.exception.ValidationError: Invalid input for query parameters 0. Value: abc. u'abc' does not match '^[0-9]*$' The exception raised also changed, which may be problematic for API consumers. We probably need another layer to transform these generated messages into something more user friendly, and perhaps consider raising HTTPBadRequest again with the nicer error message. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1655710/+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 1635657] [NEW] 'nova volume-update' corrupts BDM connection_info when guest is stopped
Public bug reported: When you attempt to 'nova volume-update' a stopped instance, the block device mapping connection_info is corrupted (it points to the new volume despite the failure). 1. create an instance (instance-1) 2. create two volumes (vol-1 & vol-2) 3. attach volume: nova volume-attach instance-1 4. nova stop instance-1 5. swap volume: nova volume-update instance-1 6. swap will fail, but the connection info points to vol-2 now Example notes using stable/newton devstack: http://paste.openstack.org/show/586715/ A similar downstream bug report: Can't re-start a stopped instance after trying to volume-update on it https://bugzilla.redhat.com/show_bug.cgi?id=1373318 ** Affects: nova Importance: Undecided Assignee: Diana Clarke (diana-clarke) Status: New ** Changed in: nova Assignee: (unassigned) => Diana Clarke (diana-clarke) -- 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/1635657 Title: 'nova volume-update' corrupts BDM connection_info when guest is stopped Status in OpenStack Compute (nova): New Bug description: When you attempt to 'nova volume-update' a stopped instance, the block device mapping connection_info is corrupted (it points to the new volume despite the failure). 1. create an instance (instance-1) 2. create two volumes (vol-1 & vol-2) 3. attach volume: nova volume-attach instance-1 4. nova stop instance-1 5. swap volume: nova volume-update instance-1 6. swap will fail, but the connection info points to vol-2 now Example notes using stable/newton devstack: http://paste.openstack.org/show/586715/ A similar downstream bug report: Can't re-start a stopped instance after trying to volume-update on it https://bugzilla.redhat.com/show_bug.cgi?id=1373318 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1635657/+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 1621536] [NEW] Remove paramiko dependency
Public bug reported: In Liberty, key pair creation (previously done via ssh-keygen) was replaced with paramiko library calls. While paramiko was listed as a dependency in Liberty, it wasn't actually used until that commit. Replace ssh exec calls with paramiko lib https://review.openstack.org/#/c/157931/ The above commit was unintentionally backwards incompatible. Specifically, it changed the SSH key ASN.1 encoding from DER to BER. Apparently golang doesn't support BER, meaning tools like Terraform no longer work with OpenStack. ssh-keygen-to-Paramiko change breaks third-party tools https://bugs.launchpad.net/nova/+bug/1483132 This has since been fixed in paramiko 2.0, but that major version bump doesn't make it into Nova until Newton, meaning these third-party tools are unusable for Liberty & Mitaka in the mean time. stable/liberty: paramiko>=1.13.0 upper-constraints: paramiko===1.16.0 stable/mitaka: paramiko>=1.16.0 upper-constraints: paramiko===1.16.0 master (newton): paramiko>=2.0 upper-constraints: paramiko===2.0.2 The bump to paramiko 2.0 was a big change, complete with a huge red warning in the changelog (which I suspect makes a backport that bumps the paramiko version to 2.0+ unrealistic for Liberty & Mitaka). http://www.paramiko.org/changelog.html http://bitprophet.org/blog/2016/04/23/paramiko-2.0-is-coming/ The switch to paramiko also introduced a number of Nova regressions along the way. Tolerate installation of pycryptodome https://review.openstack.org/#/c/279909/ crypto: Add support for Paramiko 2.x https://review.openstack.org/#/c/314592/ Drop paramiko < 2 compat code https://review.openstack.org/#/c/314639/ All this, coupled with the known security implications of using the older paramiko versions, makes me think that perhaps we should just go back to using ssh-keygen. Ideally, I'd like to backport this change all the way down to stable/liberty. ** Affects: nova Importance: Undecided Assignee: Diana Clarke (diana-clarke) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Diana Clarke (diana-clarke) -- 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/1621536 Title: Remove paramiko dependency Status in OpenStack Compute (nova): In Progress Bug description: In Liberty, key pair creation (previously done via ssh-keygen) was replaced with paramiko library calls. While paramiko was listed as a dependency in Liberty, it wasn't actually used until that commit. Replace ssh exec calls with paramiko lib https://review.openstack.org/#/c/157931/ The above commit was unintentionally backwards incompatible. Specifically, it changed the SSH key ASN.1 encoding from DER to BER. Apparently golang doesn't support BER, meaning tools like Terraform no longer work with OpenStack. ssh-keygen-to-Paramiko change breaks third-party tools https://bugs.launchpad.net/nova/+bug/1483132 This has since been fixed in paramiko 2.0, but that major version bump doesn't make it into Nova until Newton, meaning these third-party tools are unusable for Liberty & Mitaka in the mean time. stable/liberty: paramiko>=1.13.0 upper-constraints: paramiko===1.16.0 stable/mitaka: paramiko>=1.16.0 upper-constraints: paramiko===1.16.0 master (newton): paramiko>=2.0 upper-constraints: paramiko===2.0.2 The bump to paramiko 2.0 was a big change, complete with a huge red warning in the changelog (which I suspect makes a backport that bumps the paramiko version to 2.0+ unrealistic for Liberty & Mitaka). http://www.paramiko.org/changelog.html http://bitprophet.org/blog/2016/04/23/paramiko-2.0-is-coming/ The switch to paramiko also introduced a number of Nova regressions along the way. Tolerate installation of pycryptodome https://review.openstack.org/#/c/279909/ crypto: Add support for Paramiko 2.x https://review.openstack.org/#/c/314592/ Drop paramiko < 2 compat code https://review.openstack.org/#/c/314639/ All this, coupled with the known security implications of using the older paramiko versions, makes me think that perhaps we should just go back to using ssh-keygen. Ideally, I'd like to backport this change all the way down to stable/liberty. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1621536/+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 1426806] Re: flavor created successfully when flavorid neither integer nor UUID
Closing this bug since the help message in python-novaclient was updated to reflect the actual behaviour. Before: "Unique ID (integer or UUID) for the new flavor. If specifying 'auto', a UUID will be generated as ID." After: "Unique ID of the new flavor. Specifying 'auto' will generated a UUID for the ID." https://git.openstack.org/cgit/openstack/python- novaclient/commit/?id=d10486f064630bb04d0e084df456514770e62160 ** 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/1426806 Title: flavor created successfully when flavorid neither integer nor UUID Status in OpenStack Compute (nova): Invalid Bug description: version: 2014.1 icehouse-stable # nova help flavor-create ... Unique ID (integer or UUID) for the new flavor. If specifying 'auto', a UUID will be generated as id ... "id" should be integer or UUID. But when the "id" was set to non-integer or non-UUID, the flavor was also created successfully. # nova flavor-create flv-testdddfasdfsfdsfdsf jljdfsfojgnng 512 1 1 +---+--+---+--+---+--+---+-+---+ | ID| Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +---+--+---+--+---+--+---+-+---+ | jljdfsfojgnng | flv-testdddfasdfsfdsfdsf | 512 | 1| 0 | | 1 | 1.0 | True | +---+--+---+--+---+--+---+-+---+ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1426806/+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 1448564] Re: Rescue using cells fails with: unexpected keyword argument 'expected_task_state'
Marking this as invalid because I think it's already been fixed. Please feel free to re-open this bug if you can still reproduce it. ** Changed in: nova Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1448564 Title: Rescue using cells fails with: unexpected keyword argument 'expected_task_state' Status in OpenStack Compute (nova): Invalid Bug description: Instance rescue gets stuck when using cells. nova version: 2014.2.2 Using cells (parent - child setup) How to reproduce: nova rescue -> the instance "task state" stays in "rescuing". -> nova cells log of the child shows: 2015-04-26 01:26:09.475 20672 ERROR nova.cells.messaging [req-162b3318-70c3-4290-8e09-ffb9fbcef19d None] Error processing message locally: save() got an unexpected keyword argument 'expected_task_state' 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging Traceback (most recent call last): 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging File "/usr/lib/python2.7/site-packages/nova/cells/messaging.py", line 199, in _process_locally 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging resp_value = self.msg_runner._process_message_locally(self) 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging File "/usr/lib/python2.7/site-packages/nova/cells/messaging.py", line 1293, in _process_message_locally 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging return fn(message, **message.method_kwargs) 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging File "/usr/lib/python2.7/site-packages/nova/cells/messaging.py", line 698, in run_compute_api_method 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging return fn(message.ctxt, *args, **method_info['method_kwargs']) 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 224, in wrapped 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging return func(self, context, target, *args, **kwargs) 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 214, in inner 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging return function(self, context, instance, *args, **kwargs) 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 195, in inner 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging return f(self, context, instance, *args, **kw) 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 2750, in rescue 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging instance.save(expected_task_state=[None]) 2015-04-26 01:26:09.475 20672 TRACE nova.cells.messaging TypeError: save() got an unexpected keyword argument 'expected_task_state' To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1448564/+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 1569101] [NEW] Update Nova process docs to reflect the current release
Public bug reported: The Nova process docs contain a number of references to Liberty & Mitaka that should be updated to reflect the current release (Newton). http://docs.openstack.org/developer/nova/process.html ** Affects: nova Importance: Undecided Status: Confirmed ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1569101 Title: Update Nova process docs to reflect the current release Status in OpenStack Compute (nova): Confirmed Bug description: The Nova process docs contain a number of references to Liberty & Mitaka that should be updated to reflect the current release (Newton). http://docs.openstack.org/developer/nova/process.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1569101/+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 1568414] [NEW] Database Poison Warnings
Public bug reported: The following warning appears a number of times in the unit test logs. Use this bug to track the patches that eliminate these warnings. "UserWarning: This test uses methods that set internal oslo_db state, but it does not claim to use the database. This will conflict with the setup of tests that do use the database and cause failures later." Note that this warning is only emitted once per unit test worker, so new offenders will show up in the logs each time you fix a test until they are all gone. Once all of these warnings are removed, change the warning to an exception so that we don't get more of these in the future. ** Affects: nova Importance: Undecided Assignee: Diana Clarke (diana-clarke) Status: Confirmed ** Changed in: nova Assignee: (unassigned) => Diana Clarke (diana-clarke) ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1568414 Title: Database Poison Warnings Status in OpenStack Compute (nova): Confirmed Bug description: The following warning appears a number of times in the unit test logs. Use this bug to track the patches that eliminate these warnings. "UserWarning: This test uses methods that set internal oslo_db state, but it does not claim to use the database. This will conflict with the setup of tests that do use the database and cause failures later." Note that this warning is only emitted once per unit test worker, so new offenders will show up in the logs each time you fix a test until they are all gone. Once all of these warnings are removed, change the warning to an exception so that we don't get more of these in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1568414/+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 1563547] [NEW] Unable to delete instance when cinder is down
Public bug reported: When an instance is attached to a volume and cinder is down, you are unable to delete the instance, and the instance ends up stuck in an error state. This bug is reproducible on master (currently mitaka) using devstack. 1. Create an instance 2. Create a volume 3. Attach volume to instance 4. Bring the cinder api down via screen 5. Attempt to delete the instance 6. Note that the instance is not deleted 7. Note that the instance state is ERROR For example: http://paste.openstack.org/show/492359/ ** Affects: nova Importance: Undecided Assignee: Diana Clarke (diana-clarke) Status: Confirmed ** Changed in: nova Assignee: (unassigned) => Diana Clarke (diana-clarke) ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1563547 Title: Unable to delete instance when cinder is down Status in OpenStack Compute (nova): Confirmed Bug description: When an instance is attached to a volume and cinder is down, you are unable to delete the instance, and the instance ends up stuck in an error state. This bug is reproducible on master (currently mitaka) using devstack. 1. Create an instance 2. Create a volume 3. Attach volume to instance 4. Bring the cinder api down via screen 5. Attempt to delete the instance 6. Note that the instance is not deleted 7. Note that the instance state is ERROR For example: http://paste.openstack.org/show/492359/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1563547/+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 1557584] [NEW] Broken retry mechanism for 'nova image-list'
Public bug reported: You can configure a list of glance API servers in nova.conf like so: [glance] api_servers=http://192.168.122.30:9292/v1,http://192.168.122.31:9292/v1 num_retries = 5 When a call to one of the glance api servers fails, nova typically retries the call on one of the others. This is not the case for 'nova image-list'. The retry mechanism is here: https://github.com/openstack/nova/blob/83261f3106a8bdde38d258a74da777add4956290/nova/image/glance.py#L249 In the case of 'nova image-list', glanceclient returns a python generator rather than an actual list of images. Because a generator is returned, an exception will never be raised there, so the retry mechanism is never executed. https://github.com/openstack/python- glanceclient/blob/d59e341a4cd99a8488d5cf41052d9b218379ac87/glanceclient/v1/images.py#L268 This bug was originally reported downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1313254 ** Affects: nova Importance: Undecided Assignee: Diana Clarke (diana-clarke) Status: New ** Changed in: nova Assignee: (unassigned) => Diana Clarke (diana-clarke) -- 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/1557584 Title: Broken retry mechanism for 'nova image-list' Status in OpenStack Compute (nova): New Bug description: You can configure a list of glance API servers in nova.conf like so: [glance] api_servers=http://192.168.122.30:9292/v1,http://192.168.122.31:9292/v1 num_retries = 5 When a call to one of the glance api servers fails, nova typically retries the call on one of the others. This is not the case for 'nova image-list'. The retry mechanism is here: https://github.com/openstack/nova/blob/83261f3106a8bdde38d258a74da777add4956290/nova/image/glance.py#L249 In the case of 'nova image-list', glanceclient returns a python generator rather than an actual list of images. Because a generator is returned, an exception will never be raised there, so the retry mechanism is never executed. https://github.com/openstack/python- glanceclient/blob/d59e341a4cd99a8488d5cf41052d9b218379ac87/glanceclient/v1/images.py#L268 This bug was originally reported downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1313254 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1557584/+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 1537450] [NEW] [gate] functional job fails with TypeError: an integer is required (eventlet)
Public bug reported: For example: http://logs.openstack.org/85/271685/4/check/gate-nova-tox- functional/61aabd8/console.html#_2016-01-24_05_38_40_439 2016-01-24 01:35:46,325 ERROR [nova.api.openstack.wsgi] Exception handling resource: an integer is required Traceback (most recent call last): File "nova/api/openstack/wsgi.py", line 801, in _process_stack action_result = self.dispatch(meth, request, action_args) File "nova/api/openstack/wsgi.py", line 890, in dispatch return method(req=request, **action_args) File "nova/api/openstack/compute/legacy_v2/contrib/cloudpipe.py", line 136, in index for x in self._get_all_cloudpipes(context)] File "nova/api/openstack/compute/legacy_v2/contrib/cloudpipe.py", line 96, in _vpn_dict if utils.vpn_ping(vpn_ip, vpn_port): File "nova/utils.py", line 232, in vpn_ping sock.sendto(data, (address, port)) File "/Users/diana/workspace/nova/.tox/functional/lib/python2.7/site-packages/eventlet/greenio/base.py", line 382, in sendto return self._send_loop(self.fd.sendto, data, address, flags) File "/Users/diana/workspace/nova/.tox/functional/lib/python2.7/site-packages/eventlet/greenio/base.py", line 361, in _send_loop total_sent += send_method(data[total_sent:], *args) TypeError: an integer is required This is caused by the recent eventlet release: https://pypi.python.org/pypi/eventlet/0.18.0 In particular, this issue: "Handle blocking I/O errors in GreenSocket". https://github.com/eventlet/eventlet/issues/274 https://github.com/eventlet/eventlet/commit/bc4d1b5d362e5baaeded35b1e339b9db08172dd2 To reproduce (assuming your dev env is using eventlet 0.18.0): tox -e functional nova.tests.functional.api_sample_tests.test_cloudpipe.CloudPipeSampleTest ** Affects: nova Importance: Undecided Status: New ** Summary changed: - [gate] functional job fails with TypeError: an integer is required + [gate] functional job fails with TypeError: an integer is required (eventlet) -- 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/1537450 Title: [gate] functional job fails with TypeError: an integer is required (eventlet) Status in OpenStack Compute (nova): New Bug description: For example: http://logs.openstack.org/85/271685/4/check/gate-nova-tox- functional/61aabd8/console.html#_2016-01-24_05_38_40_439 2016-01-24 01:35:46,325 ERROR [nova.api.openstack.wsgi] Exception handling resource: an integer is required Traceback (most recent call last): File "nova/api/openstack/wsgi.py", line 801, in _process_stack action_result = self.dispatch(meth, request, action_args) File "nova/api/openstack/wsgi.py", line 890, in dispatch return method(req=request, **action_args) File "nova/api/openstack/compute/legacy_v2/contrib/cloudpipe.py", line 136, in index for x in self._get_all_cloudpipes(context)] File "nova/api/openstack/compute/legacy_v2/contrib/cloudpipe.py", line 96, in _vpn_dict if utils.vpn_ping(vpn_ip, vpn_port): File "nova/utils.py", line 232, in vpn_ping sock.sendto(data, (address, port)) File "/Users/diana/workspace/nova/.tox/functional/lib/python2.7/site-packages/eventlet/greenio/base.py", line 382, in sendto return self._send_loop(self.fd.sendto, data, address, flags) File "/Users/diana/workspace/nova/.tox/functional/lib/python2.7/site-packages/eventlet/greenio/base.py", line 361, in _send_loop total_sent += send_method(data[total_sent:], *args) TypeError: an integer is required This is caused by the recent eventlet release: https://pypi.python.org/pypi/eventlet/0.18.0 In particular, this issue: "Handle blocking I/O errors in GreenSocket". https://github.com/eventlet/eventlet/issues/274 https://github.com/eventlet/eventlet/commit/bc4d1b5d362e5baaeded35b1e339b9db08172dd2 To reproduce (assuming your dev env is using eventlet 0.18.0): tox -e functional nova.tests.functional.api_sample_tests.test_cloudpipe.CloudPipeSampleTest To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1537450/+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 1532340] [NEW] No such file or directory: '/proc/self/mounts'
Public bug reported:
I'm seeing unit test failures like the following on my mac since this
was merged:
https://github.com/openstack/nova/commit/b3879bd199036a9327a32d7c7cacdff3a9c9807d
https://github.com/openstack/nova/blob/b1588cea68d2037dfc2e792b25fbb56d76b7d439/nova/virt/libvirt/host.py#L1005
Traceback (most recent call last):
File "nova/tests/unit/virt/test_virt_drivers.py", line 55, in wrapped_func
return f(self, *args, **kwargs)
File "nova/tests/unit/virt/test_virt_drivers.py", line 380, in
test_power_off
instance_ref, network_info = self._get_running_instance()
File "nova/tests/unit/virt/test_virt_drivers.py", line 264, in
_get_running_instance
[], 'herp', network_info=network_info)
File "nova/virt/libvirt/driver.py", line 2506, in spawn
write_to_disk=True)
File "nova/virt/libvirt/driver.py", line 4402, in _get_guest_xml
context)
File "nova/virt/libvirt/driver.py", line 4223, in _get_guest_config
self._update_guest_cputune(guest, flavor, virt_type)
File "nova/virt/libvirt/driver.py", line 3571, in _update_guest_cputune
is_able = self._host.is_cpu_control_policy_capable()
File "nova/virt/libvirt/host.py", line 1005, in
is_cpu_control_policy_capable
with open("/proc/self/mounts", "r") as fd:
IOError: [Errno 2] No such file or directory: '/proc/self/mounts'
** Affects: nova
Importance: Undecided
Status: New
** Description changed:
I'm seeing unit test failures on my mac:
- Traceback (most recent call last):
- File "nova/tests/unit/virt/test_virt_drivers.py", line 55, in
wrapped_func
- return f(self, *args, **kwargs)
- File "nova/tests/unit/virt/test_virt_drivers.py", line 380, in
test_power_off
- instance_ref, network_info = self._get_running_instance()
- File "nova/tests/unit/virt/test_virt_drivers.py", line 264, in
_get_running_instance
- [], 'herp', network_info=network_info)
- File "nova/virt/libvirt/driver.py", line 2506, in spawn
- write_to_disk=True)
- File "nova/virt/libvirt/driver.py", line 4402, in _get_guest_xml
- context)
- File "nova/virt/libvirt/driver.py", line 4223, in _get_guest_config
- self._update_guest_cputune(guest, flavor, virt_type)
- File "nova/virt/libvirt/driver.py", line 3571, in _update_guest_cputune
- is_able = self._host.is_cpu_control_policy_capable()
- File "nova/virt/libvirt/host.py", line 1005, in
is_cpu_control_policy_capable
- with open("/proc/self/mounts", "r") as fd:
- IOError: [Errno 2] No such file or directory: '/proc/self/mounts'
+ Traceback (most recent call last):
+ File "nova/tests/unit/virt/test_virt_drivers.py", line 55, in
wrapped_func
+ return f(self, *args, **kwargs)
+ File "nova/tests/unit/virt/test_virt_drivers.py", line 380, in
test_power_off
+ instance_ref, network_info = self._get_running_instance()
+ File "nova/tests/unit/virt/test_virt_drivers.py", line 264, in
_get_running_instance
+ [], 'herp', network_info=network_info)
+ File "nova/virt/libvirt/driver.py", line 2506, in spawn
+ write_to_disk=True)
+ File "nova/virt/libvirt/driver.py", line 4402, in _get_guest_xml
+ context)
+ File "nova/virt/libvirt/driver.py", line 4223, in _get_guest_config
+ self._update_guest_cputune(guest, flavor, virt_type)
+ File "nova/virt/libvirt/driver.py", line 3571, in _update_guest_cputune
+ is_able = self._host.is_cpu_control_policy_capable()
+ File "nova/virt/libvirt/host.py", line 1005, in
is_cpu_control_policy_capable
+ with open("/proc/self/mounts", "r") as fd:
+ IOError: [Errno 2] No such file or directory: '/proc/self/mounts'
since this was merged:
https://github.com/openstack/nova/commit/b3879bd199036a9327a32d7c7cacdff3a9c9807d
+
https://github.com/openstack/nova/blob/b1588cea68d2037dfc2e792b25fbb56d76b7d439/nova/virt/libvirt/host.py#L1005
** Description changed:
- I'm seeing unit test failures on my mac:
+ I'm seeing unit test failures like the following on my mac:
Traceback (most recent call last):
File "nova/tests/unit/virt/test_virt_drivers.py", line 55, in
wrapped_func
return f(self, *args, **kwargs)
File "nova/tests/unit/virt/test_virt_drivers.py", line 380, in
test_power_off
instance_ref, network_info = self._get_running_instance()
File "nova/tests/unit/virt/test_virt_drivers.py", line 264, in
_get_running_instance
[], 'herp', network_info=network_info)
File "nova/virt/libvirt/driver.py", line 2506, in spawn
write_to_disk=True)
File "nova/virt/libvirt/driver.py", line 4402, in _get_guest_xml
context)
File "nova/virt/libvirt/driver.py", line 4223, in _get_guest_config
self._update_guest_cputune(guest, flavor, virt_type)
[Yahoo-eng-team] [Bug 1408591] Re: AttributeError: "'Instance' object has no attribute 'get_flavor'" when call compute_api.update
Closing. Like Melanie said, the compute/api::update() method was removed in this commit: https://github.com/openstack/nova/commit/01d28bcadd3db9255dd46138caa4bd31837baaf1 ** 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/1408591 Title: AttributeError: "'Instance' object has no attribute 'get_flavor'" when call compute_api.update Status in OpenStack Compute (nova): Invalid Bug description: In nova/notifications.py(370)info_from_instance(): The AttributeError: "'Instance' object has no attribute 'get_flavor'" throws on: instance_type = instance.get_flavor() The stacktrace is: -> self.compute_api.update(context, local_instance, **base_options) /usr/lib/python2.7/site-packages/nova/compute/api.py(235)wrapped() -> return func(self, context, target, *args, **kwargs) /usr/lib/python2.7/site-packages/nova/compute/api.py(1501)update() -> refs = self._update(context, instance, **kwargs) /usr/lib/python2.7/site-packages/nova/compute/api.py(1510)_update() -> instance_ref, service="api") /usr/lib/python2.7/site-packages/nova/notifications.py(146)send_update() -> old_display_name=old_display_name) /usr/lib/python2.7/site-packages/nova/notifications.py(226)_send_instance_update_notification() -> payload = info_from_instance(context, instance, None, None) > /usr/lib/python2.7/site-packages/nova/notifications.py(370)info_from_instance() -> instance_type = instance.get_flavor() I tried pass into the db instance and nova object instance, I believe this should be the defect. Please look into it. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1408591/+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 1447164] Re: require_admin_context() does not account for policy.json rulesets
Thanks for the additional context, Alex. I'll close this bug (mark it as invalid). ** Changed in: nova Status: Confirmed => Invalid ** Changed in: nova Assignee: Diana Clarke (diana-clarke) => (unassigned) -- 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/1447164 Title: require_admin_context() does not account for policy.json rulesets Status in OpenStack Compute (nova): Invalid Bug description: The API RBAC is done using a policy.json file which allows fine-grained control over each API endpoint by setting specific rules. Consequently, some defaulted admin-only endpoints can be opened by modifying their corresponding policy rules to be for anyone. Unfortunately, in many places (in the DB and at the API level following the blueprint api-policy-v3 ), there is a call to context.require_admin_context() which is just checking if the user is admin or no but doesn't match with the policy rules. As we all agreed with api-policy-v3 that RBAC should be done at the API level, there is no reason to keep that call to context.require_admin_context() and we should assume that policy.json is the single source of truth for knowing the access rights. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1447164/+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
