Cannot filter 'soft-deletd' instances via nova api

[Yufang Zhang]

In nova-api, both DELETED and SOFT_DELETED are mapped to 'DELETED'. Thus we cannot filer 'soft-deleted' instances via nova-api, like:

nova list --status SOFT_DELETED

[Matt Riedemann (mriedem)]

I took a look at the blame around this in nova.api.openstack.common and there is some blueprint work and vm_state/task_state management cleanup history here, but I can't tell if this was just an oversight or intentional.

See here: http://wiki.openstack.org/VMState

[Matt Riedemann (mriedem)]

My guess is because the ec2 API doesn't appear to make a distinction between deleted and soft-delete (it considers both states as terminated), maybe the same assumption was made in the OS API and was just an oversight. I can take a crack at changing the OS API mapping and if it's obviously wrong it can be shot down in review.

[Matt Riedemann (mriedem)]

Looking at the OS API server list code, it doesn't do a great job of letting the user know if they gave an invalid status value either, it just returns nothing:

https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L514

At a minimum this should be logging something because if you get that far, the user is obviously trying to filter on status, they just aren't using the right thing. The problem I see after that is how the user does know what the right thing is, since I don't see it listed as available options in the docs for the server list API. To be harsh, we could raise a bad request exception if the status value isn't mapped to a vm_state, I'll see what the feelings are on that in a review.

[OpenStack Infra (hudson-openstack)]

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

[Matt Riedemann (mriedem)]

Dropping my review due to a -2 from the PTL with this:

"This patch only allows SOFT_DELETED as a filter as input. As far as I can tell, SOFT_DELETED is never exposed via the API. I don't think it makes sense to allow it as input unless there is a more sweeping change to expose this concept via the API. If we did *that* (expose the concept of a soft delete), I would also expect the ability to undo a delete that is pending ... basically I think it should be nothing, or much more change than this (I think I just prefer nothing personally)."