yahoo-eng-team team mailing list archive

[John Garbutt <john@xxxxxxxxxxxxxxx>]

Pools hardy work, this is just the tip of ice burg and noise.

** Changed in: nova
       Status: Confirmed => Won't Fix

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

Title:
  Need to deal with XenAPI pool master election

Status in OpenStack Compute (Nova):
  Won't Fix

Bug description:
  The XenAPI host aggregates support is currently unable to deal with
  the case when the pool master dies.

  The master re-election should be left to the administrator (unless we
  are able to leverage XenServer HA), because it is hard in general to
  tell if the master is truly dead, or there was just a loss of
  management network connectively. It is tricky to ensure the master
  does not write the VM disk during the process.

  The best approach is to ensure to find out which memeber of the
  aggregate has become the master, in the case where the master is
  changed.

  This is important because all VM operations are sent to the master of
  the pool (such as VM start and stop)

  Pools were added in Essex, and this issue was not address in the
  initial implementation.

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