OpenStack Compute (nova)

Disabling/enabling host via API returns HTTP 400 Bad Request

Bug #1060884 reported by Mariusz Pietrzyk
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Medium
Mark McLoughlin
OpenStack Compute (nova) 2013.1 "grizzly"

Bug Description

Disabling/enabling hosts ends with 400 response, but in logs i see 'Setting host cc to disabled' and the request is then forwarded to nova-compute.

Here are the steps.

First I'm making the following request:

PUT os-hosts/cc with body {"status" : "disable"}

In the nova-api.log I see my request

2012-10-03 11:48:59 INFO nova.api.openstack.wsgi [req-66e9dcf9-19c4-41de-8232-32834137f04d 941cdd94696e474a951d5ed112d4d4c9 4674d940971f4532a8747baf1af30d9b] PUT http://localhost:8774/v1.1/4674d940971f4532a8747baf1af30d9b/os-hosts/cc?ignore_awful_caching1349257739
2012-10-03 11:48:59 AUDIT nova.api.openstack.compute.contrib.hosts [req-66e9dcf9-19c4-41de-8232-32834137f04d 941cdd94696e474a951d5ed112d4d4c9 4674d940971f4532a8747baf1af30d9b] Setting host cc to disabled.
2012-10-03 11:48:59 DEBUG nova.rpc.amqp [req-66e9dcf9-19c4-41de-8232-32834137f04d 941cdd94696e474a951d5ed112d4d4c9 4674d940971f4532a8747baf1af30d9b] Making asynchronous call on compute.cc ... from (pid=16703) multicall /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:326
2012-10-03 11:48:59 DEBUG nova.rpc.amqp [req-66e9dcf9-19c4-41de-8232-32834137f04d 941cdd94696e474a951d5ed112d4d4c9 4674d940971f4532a8747baf1af30d9b] MSG_ID is 2bc447466a644e37bf9ec1c20ac51757 from (pid=16703) multicall /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:329
2012-10-03 11:49:00 INFO nova.api.openstack.wsgi [req-66e9dcf9-19c4-41de-8232-32834137f04d 941cdd94696e474a951d5ed112d4d4c9 4674d940971f4532a8747baf1af30d9b] HTTP exception thrown: None
2012-10-03 11:49:00 INFO nova.api.openstack.wsgi [req-66e9dcf9-19c4-41de-8232-32834137f04d 941cdd94696e474a951d5ed112d4d4c9 4674d940971f4532a8747baf1af30d9b] http://localhost:8774/v1.1/4674d940971f4532a8747baf1af30d9b/os-hosts/cc?ignore_awful_caching1349257739 returned with HTTP 400

Then in nova-compute.log i see

2012-10-03 11:48:59 DEBUG nova.rpc.amqp [-] received {u'_context_roles': [u'admin'], u'_msg_id': u'2bc447466a644e37bf9ec1c20ac51757', u'_context_read_deleted': u'no', u'_context_request_id': u'req-66e9dcf9-19c4-41de-8232-32834137f04d', u'args': {u'enabled': False}, u'_context_auth_token': '<SANITIZED>', u'_context_is_admin': True, u'_context_project_id': u'4674d940971f4532a8747baf1af30d9b', u'_context_timestamp': u'2012-10-03T09:48:59.977461', u'_context_user_id': u'941cdd94696e474a951d5ed112d4d4c9', u'method': u'set_host_enabled', u'_context_remote_address': u'127.0.0.1'} from (pid=17768) _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160
2012-10-03 11:48:59 DEBUG nova.rpc.amqp [req-66e9dcf9-19c4-41de-8232-32834137f04d 941cdd94696e474a951d5ed112d4d4c9 4674d940971f4532a8747baf1af30d9b] unpacked context: {'user_id': u'941cdd94696e474a951d5ed112d4d4c9', 'roles': [u'admin'], 'timestamp': '2012-10-03T09:48:59.977461', 'auth_token': '<SANITIZED>', 'remote_address': u'127.0.0.1', 'is_admin': True, 'request_id': u'req-66e9dcf9-19c4-41de-8232-32834137f04d', 'project_id': u'4674d940971f4532a8747baf1af30d9b', 'read_deleted': u'no'} from (pid=17768) _safe_log /usr/lib/python2.7/dist-packages/nova/rpc/common.py:160

but host's status doesn't get changed.

My version is 2012.1.1-9

See original description
Mariusz Pietrzyk (wijet-b)
description: updated
Mark McLoughlin (markmc)
Changed in nova:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Mark McLoughlin (markmc)
Revision history for this message
Mark McLoughlin (markmc) wrote :

bug #1086798 needs to be fixed first

Revision history for this message
Mark McLoughlin (markmc) wrote :

With the libvirt diver and latest grizzly, I'm seeing:

 $> nova host-update --status disable f17
 ERROR: Bad request (HTTP 400) (Request-ID: req-f746e6c4-e8fe-492d-837d-441b91161181)
 $> nova host-update --maintenance enable f17
 ERROR: The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-c75dfe3e-cddb-42b2-a761-2a44576e0886)
 $> nova host-action --action reboot f17
 ERROR: The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-b80718eb-ea22-4a5d-9d5a-8db71b9dc348)

Revision history for this message
Mark McLoughlin (markmc) wrote :

Fix will make it:

 $ nova host-update --status disable f17
ERROR: Virt driver does not implement host disabled status. (HTTP 501) (Request-ID: req-b1329b90-f32a-450d-a5c7-0608db3a767b)
 $ nova host-update --maintenance enable f17
ERROR: Virt driver does not implement host maintenance mode. (HTTP 501) (Request-ID: req-e609759a-d788-4025-b99d-29c10c0c1d0c)
 $ nova host-action --action reboot f17
ERROR: Virt driver does not implement host power management. (HTTP 501) (Request-ID: req-158c6dec-725b-4a4a-ac32-384fb95ba91d)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

Fix proposed to branch: master
Review: https://review.openstack.org/17565

Changed in nova:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/17565
Committed: http://github.com/openstack/nova/commit/1dc6c806b32044420bf17d3076dd712185b7ac07
Submitter: Jenkins
Branch: master

commit 1dc6c806b32044420bf17d3076dd712185b7ac07
Author: Mark McLoughlin <email address hidden>
Date: Wed Dec 5 23:13:37 2012 +0000

    Fix handling of unimplemented host actions

    Fixes bug #1060884

    Host actions like enable/disable, maintenance mode and power management
    are not implemented in most virt drivers.

    In the case of set_host_enabled() in the libvirt driver, we have a no-op
    implementation. In other cases we have an implementation which raises
    NotImplementedError. Since the default implementation is to do this, we
    should just remove the redundant methods from the drivers which don't
    actually implement these actions. This ensures NotImplementedError is
    consistently raised.

    On the API side, rather than looking at the return value of these
    methods to determine whether they're implemented, we should just catch
    NotImplementedError and return a sensible error message.

    In order to do this, we need to ensure the NotImplementedError is
    properly deserialized from the RemoteError which will encapsualte
    it. The fix for bug #1086798 ensures this happens.

    Finally, add some tests to make sure we properly respond with 501
    when the virt driver doesn't implement these actions.

    Change-Id: I2d4fc51a4b16d5230e61bde75915142ea450557d

Changed in nova:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in nova:
milestone: none → grizzly-2
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in nova:
milestone: grizzly-2 → 2013.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.