On Wed, Oct 01, 2014, Chris Friesen <chris.frie...@windriver.com> 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? Which customer would ever > expect the VM to be in an error state? > > 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). > > 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. > > Thoughts?
I'm happy you brought this up because I've had a similar proposal in the bouncing around in the back of my head lately. ERROR is a pet peeve of mine because it doesn't tell you the operational state of the instance. It may be running or it may not be running. It also ends up complicating logic quite a bit (we have a very ugly patch to allow users to revert resizes in ERROR). Also, in a few places we have to store vm_state off into instance metadata (key 'old_vm_state') so it can be restored to the correct state (for things like RESCUED). This is fairly ugly. I've wanted to sit down and work through all of the different vm_state transitions and figure out to make it all less confusing. I just haven't had the time to do it yet :( JE _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev