On 18 June 2014 21:57, Jay Pipes <jaypi...@gmail.com> wrote: > 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.
+1 for one "move" API, the two evolved independently, in different drivers, its time to unify them! That plan got stuck behind the refactoring of live-migrate and migrate to the conductor, to help unify the code paths. But it kinda got stalled (I must rebase those patches...). Just to be clear, I am against removing resize down from v2 without a deprecation cycle. But I am pro starting that deprecation cycle. John _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
