On Tue, Jun 24, 2014 at 10:55:41AM +0000, Day, Phil wrote: > > -----Original Message----- > > From: John Garbutt [mailto:j...@johngarbutt.com] > > Sent: 23 June 2014 10:35 > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction > > as part of resize ? > > > > 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 > > > I'm not sure Daniel and Jay are arguing for the same thing here John: > I *think* Daniel is saying "drop resize altogether" and Jay is saying > "unify it with migration" - so I'm a tad confused which of those you're > agreeing with.
Yes, I'm personally for removing resize completely since, IMHO, no matter how many bugs we fix it is always going to be a mess. That said I realize that people probably find resize-up useful, so I won't push hard to kill it - we should just recognize that it is always going to be a mess which does not result in the same setup you'd get if you booted fresh with the new settings. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
