Open Stack

On 10/01/2014 01:23 PM, Jay Pipes wrote:
> On 10/01/2014 03:07 PM, Chris Friesen wrote:
>> Currently in nova we have the "vm_state", which according to the code
>> comments is supposed to represent "a VM's current stable (not
>> transition) state", or "what the customer expect the VM to be".
>>
>> However, we then added in an ERROR state.  How does this possibly make
>> sense given the above definition?
>
> Where do you see that vm_state is intended to be "what the customer
> expects the VM to be"?

 From nova/compute/vm_states.py:
'vm_state describes a VM's current stable (not transition) state. That 
is, if there is no ongoing compute API calls (running tasks), vm_state 
should reflect what the customer expect the VM to be.'

Also, from http://wiki.openstack.org/VMState:
'vm_state reflects the stable state based on API calls, matching user 
expectation, revised “top-down” within API implementation.'


Now granted, the wiki also says 'If the task fails and is not possible 
to rollback, the vm_state is set to ERROR.'  I don't particularly like 
that behaviour, which is why I'd like to see a separate "actual state".

> I don't think this is all that useful. I think what would be more useful
> is changing the Nova API to perform actions against an instance using a
> POST /servers/{server_id}/tasks call, allow a user to see a history of
> what actions were taken against an instance with a call to GET
> /servers/{server_id}/tasks and allow a user to see the progress of a
> particular task (say, a rebuild) by calling GET /tasks/{task_id}/items.

Yep, I like that idea.  But I think it's orthogonal to the issue of 
desired vs actual state.  When you start a task it could change the 
"desired" state, and when the task completes the "actual" state should 
match the "expected state.

> I proposed as much here:
>
> http://docs.oscomputevnext.apiary.io/#servertask

Just curious, where is the equivalent of "evacuate"?

> http://docs.oscomputevnext.apiary.io/#servertaskitem
>
>> This would more easily allow for recovery actions, since if the actual
>> state changes to ERROR (or similar) we would still have the
>> expected/desired state available for reference when trying to take
>> recovery actions.

Where would the expected/desired state be stored?  Or is it implicit in 
the most recent task attempted for the instance in question?

> I think a task-based API and internal system that uses taskflow to
> organize related tasks with state machine changes is the best design to
> work towards.

I think something like this would certainly be an improvement over what 
we have now. That said, I don't see that as mutually exclusive with an 
explicit distinction between desired and actual state.  I think having 
"nova list" or the dashboard equivalent show both states would be useful.

Chris