yahoo-eng-team team mailing list archive

[Adam Gandelman <1158509@xxxxxxxxxxxxxxxxxx>]

** Changed in: nova/grizzly
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1158509

Title:
  Some Compute API methods unnecessarily alter the vm_state.

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) grizzly series:
  Fix Released

Bug description:
  Several methods in nova.compute.api alter the vm_state value before
  proceeding with the actual work. In some cases, this will be a
  semantic no-op as it is set to a value specified in
  check_instance_state decorator. In other cases, it seems possible that
  a race condition might occur. However, in other cases when multiple
  valid start states are allowed, the initial state may be changed to
  something other than the initial state. This is a violation of the
  suggested rules around vm_state changes (i.e. the vm_state should not
  be modified until a task is complete) and leaves us in a bind: since
  we do not know what the initial state actually was, we cannot
  reasonably recover and the aforementioned set of rules state that the
  vm_state should be set to ERROR if a problem with the operation
  occurs. There are several instances where setting the instance state
  to ERROR is completely avoidable an unecessary if the initial vm_state
  is left alone until the task is complete and error occurs.

  Some examples are:

  rescue
  suspend
  pause

  Judging from the code history, this seems like it might be a remnant
  from a time when there was some mixing between what is now the
  vm_state, task_state and power_state values.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1158509/+subscriptions