Open Stack

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"? An ERROR vm_state is pretty clearly a stable 
state (i.e. it's not a transient state).

 >  Which customer would ever expect the
> VM to be in an error state?

Nobody would. But I don't see where you are getting that definition of 
what vm_state means...

> Given this, I wonder whether it might make sense to formally distinguish
> between the expected/desired state (i.e. the state that the customer
> wants the VM to be in), and the actual state (i.e. the state that nova
> thinks the VM is in).

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.

I proposed as much here:

http://docs.oscomputevnext.apiary.io/#servertask
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.

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.

Best,
-jay