Open Stack

On Tue, Jun 24, 2014 at 10:55:41AM +0000, Day, Phil wrote:
> > -----Original Message-----
> > From: John Garbutt [mailto:john at 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 <jaypipes at 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 :|