Open Stack

On 24 June 2014 16:40, Jay Pipes <jaypipes at gmail.com> wrote:
> 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.

OK, I got the wrong end of the stick, sorry.

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

Resize down should probably get deprecated and die.

But I think resize up is quite useful.

If we make snapshot, then build work well for all use cases, then
resize up could die too.

But I am still on the fence here, mostly due to how slow snapshots can
be, and loosing your IP addresses across the whole process. But thats
more a problem for me than it is for nova users as a whole.

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

I agree, we need to bring together all move APIs into a single API.
Mostly thinking about migrate and live-migrate.

We could probably leave resize behind for now, but I really want to do
resize up like this:
* live migrate to host where it fits
* now shutdown guest and do the resize up of the disk
And there are specs about hot plugging CPUs as soon as you get to the
destination, if thats all you need to do.

Thanks,
John