Resize Flavor Validation Overly Restrictive, Blocks VCPU Increase + More

[Auston McReynolds]

the resize instance validation is overly restrictive. in short, the resize instance operation should be permitted if the new flavor id is different than the old flavor id.

why: even if the ram, cpu, and root disk are the same, a flavor can have scheduler hints placed on it.

the logic today blocks these very valid scenarios:

(1) resize to a flavor with more vcpus, but the same amount of ram
(2) resize to a flavor with the same amount of ram + vcpus, but more root-disk.
(3) resize to a flavor with the same ram + vcpus + root-or-ephemeral, but different flavor-id.
(4) etc.

[Auston McReynolds (amcrn)]

i'm leaving this unassigned at the moment because i'm working on a few other bugs; if anyone is interested in fixing this, go for it.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/164547

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/164547
Committed: https://git.openstack.org/cgit/openstack/trove/commit/?id=5d5cc38467d0caa0366fb5a05b8f82343586a476
Submitter: Jenkins
Branch: master

commit 5d5cc38467d0caa0366fb5a05b8f82343586a476
Author: dagnello <email address hidden>
Date: Sun Mar 15 14:05:42 2015 -0700

    Updating Flavor Resize Restrictions

    Updating instance flavor resize restriction logic to:
    Resize the instance if current flavor id and new flavor id are
    different.
    Except when:
      * current flavor allows for volume support and new flavor does not
      * current flavor has ephemeral support enabled and new flavor does
        not

    Change-Id: If708f795858489114cfa09901591d95b1bcb530b
    closing-bug: 1382931