yahoo-eng-team team mailing list archive

["Kyle L. Henderson" <kyleh@xxxxxxxxxx>]

Public bug reported:

In nova/compute/manager.py, _sync_power_states() uses a synchronized()
lock to lock on the instance uuid before reconciling the power states of
the instance between OpenStack and the compute driver.  It purposely
conflicts with the instance uuid lock on deployment
(do_build_and_run_instance) .  However, inside the lock (in
_query_driver_power_state_and_sync) the first thing it does is to see if
there is a task state and if so skips sync'ing the power state.

The result of synchronizing with the deployment is that all periodic
tasks can be hung up behind a single deploy of an instance.  There is no
reason, that I can see, why the checking the task state can't be done
outside the synchronized lock which would make it skip instances being
deployed and would prevent periodic tasks from being hung behind a
deployment.

So basically, the check for a task state should be moved to be outside
the lock and that would avoid hanging periodic tasks and would result in
the same semantics of the existing syncing of power states.

** Affects: nova
     Importance: Undecided
         Status: New

-- 
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/1362194

Title:
  _sync_power_state locks during deployment

Status in OpenStack Compute (Nova):
  New

Bug description:
  In nova/compute/manager.py, _sync_power_states() uses a synchronized()
  lock to lock on the instance uuid before reconciling the power states
  of the instance between OpenStack and the compute driver.  It
  purposely conflicts with the instance uuid lock on deployment
  (do_build_and_run_instance) .  However, inside the lock (in
  _query_driver_power_state_and_sync) the first thing it does is to see
  if there is a task state and if so skips sync'ing the power state.

  The result of synchronizing with the deployment is that all periodic
  tasks can be hung up behind a single deploy of an instance.  There is
  no reason, that I can see, why the checking the task state can't be
  done outside the synchronized lock which would make it skip instances
  being deployed and would prevent periodic tasks from being hung behind
  a deployment.

  So basically, the check for a task state should be moved to be outside
  the lock and that would avoid hanging periodic tasks and would result
  in the same semantics of the existing syncing of power states.

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