Open Stack

On 06/24/2014 07:32 AM, Daniel P. Berrange wrote:
> 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.

I am of the opinion that the different API extensions and the fact that 
they have evolved separately have created a giant mess for users, and 
that we should consolidate the API into a single "move" API that can 
take an optional new set of resources (via a new specified flavor) and 
should automatically "live move" the instance if it is possible, and 
fall back to a cold move if it isn't possible, with no confusing options 
or additional/variant API calls needed by the user.

Best,
-jay