Open Stack

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