server status attribute different than rackspace style in OS API

[Mike Mayo]

In the server JSON for GET /servers/detail, the status attribute is all lower case (i.e. "active"), whereas the Rackspace Cloud API server status is in all caps (i.e. "ACTIVE").

[Thierry Carrez (ttx)]

Looks like a spec violation.
"possible values for the status attribute include: UNKNOWN, PREPARING, ACTIVE, QUEUED, FAILED"

[Ken Pepple (ken-pepple)]

The case problem is an easy fix (branch attached) - however, the bigger problem is that we seem to have several more status messages than we have defined in the spec and several in the spec appear to be unused:

nova/api/openstack/views/servers.py:59
        power_mapping = {
            None: 'build',
            power_state.NOSTATE: 'build',
            power_state.RUNNING: 'active',
            power_state.BLOCKED: 'active',
            power_state.SUSPENDED: 'suspended',
            power_state.PAUSED: 'paused',
            power_state.SHUTDOWN: 'active',
            power_state.SHUTOFF: 'active',
            power_state.CRASHED: 'error',
            power_state.FAILED: 'error'}

Do we want to correct these with ...
        power_mapping = {
            None: 'UNKNOWN',
            power_state.NOSTATE: 'PREPARING',
            power_state.RUNNING: 'ACTIVE',
            power_state.BLOCKED: 'QUEUED',
            power_state.SUSPENDED: 'ACTIVE',
            power_state.PAUSED: 'ACTIVE',
            power_state.SHUTDOWN: 'ACTIVE',
            power_state.SHUTOFF: 'ACTIVE',
            power_state.CRASHED: 'FAILED',
            power_state.FAILED: 'FAILED'}

I don't believe this is confined to the openstack api either ... how do we want to proceed ? I have the case fix in the linked branch.

[Brian Lamar (blamar)]

Ken, thanks for the investigation... while I don't have any better plans for a long term solution I'd love to see that second mapping in the code for a short term solution. Not having dealt with a lot of the virtualization code, I'm not sure that the status should always be based on the 'power_state' but your branch would be a good start with the second power_mapping example in my opinion.

Thanks again.