Until the resource providers work is done, there is no fix for this.
Under current architecture this is a Won't Fix

** Changed in: nova
       Status: New => 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/1633990

Title:
  resize or migrate instance will get failed if two compute hosts are
  set in different rbd pool

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

Bug description:
  We are now facing a nova operation issue about setting different ceph rbd 
pool to each corresponding nova compute node in one available zone. For 
instance:
  (1) compute-node-1  in az1 and set images_rbd_pool=pool1
  (2) compute-node-2  in az1 and set images_rbd_pool=pool2
  This setting can normally work fine.

  But problem encountered when doing resize/migrate instance. For instance, 
when try to resize an instance-1 originally in compute-node-1, then nova will 
do schedule procedure, assuming that nova-scheduler get the chosen compute node 
is compute-node-2. Then the nova will get the following error:
  http://paste.openstack.org/show/585540/.

  This exception is because that in compute-node-2 nova can't find pool1 vm1 
disk. So is there a way nova can handle this? Similar thing in cinder, you may 
see a cinder volume has host attribute like:
  host_name@pool_name#ceph.

  Why we use such setting is because that while doing storage capacity
  expansion we want to avoid the influence of ceph rebalance.

  One solution we found is AggregateInstanceExtraSpecsFilter, this can 
coordinate working with Host Aggregates metadata and flavor metadata.
  We try to create Host Aggregates like:
  az1-pool1 with hosts compute-node-1, and metadata {ceph_pool: pool1};
  az1-pool2 with hosts compute-node-2, and metadata {ceph_pool: pool2};
  and create flavors like:
  flavor1-pool1 with metadata {ceph_pool: pool1};
  flavor2-pool1 with metadata {ceph_pool: pool1};
  flavor1-pool2 with metadata {ceph_pool: pool2};
  flavor2-pool2 with metadata {ceph_pool: pool2};

  But this may introduce a new issue about the create_instance. Which flavor 
should be used? The business/application layer seems need to add it's own 
flavor scheduler. And this can also
  cause a compute service capacity issue. If choice one flavor to resize, the 
scheduler will use the AggregateInstanceExtraSpecsFilter to limit the 
destination host to the same rbd pool, what if there is no available compute 
host? what if there has no enough memory or CPU? So this is not the best 
solution.

  So here finally, I want to ask, if there is a best practice about
  using multiple ceph rbd pools in one available zone.

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Reply via email to