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:


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.


OpenStack-dev mailing list

Reply via email to