On 06/17/2014 05:42 PM, Daniel P. Berrange wrote:
On Tue, Jun 17, 2014 at 04:32:36PM +0100, Pádraig Brady wrote:
On 06/13/2014 02:22 PM, Day, Phil wrote:
I guess the question I’m really asking here is: “Since we know resize down
won’t work in all cases,
and the failure if it does occur will be hard for the user to detect,
should we just block it at the API layer and be consistent across all
Hypervisors ?”
+1
There is an existing libvirt blueprint:
https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down
which I've never been in favor of:
https://bugs.launchpad.net/nova/+bug/1270238/comments/1
All of the functionality around resizing VMs to match a different
flavour seem to be a recipe for unleashing a torrent of unfixable
bugs, whether resizing disks, adding CPUs, RAM or any other aspect.
+1
I'm of the opinion that we should plan to rip resize functionality out
of (the next major version of) the Compute API and have a *single*,
*consistent* API for migrating resources. No more "API extension X for
migrating this kind of thing, and API extension Y for this kind of
thing, and API extension Z for migrating /live/ this type of thing."
There should be One "move" API to Rule Them All, IMHO.
Best,
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
