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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
