Open Stack

> -----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.

Phil