Open Stack

2014/1/22 Christopher Yeoh <cbkyeoh at gmail.com>

> On Mon, Jan 20, 2014 at 6:10 PM, Jay Lau <jay.lau.513 at gmail.com> wrote:
>
>> Hey,
>>
>> I have to bring up this topic again. A patch
>> https://review.openstack.org/#/c/66101/ has been uploaded for review to
>> resolve the cold migration auto confirm issue.
>>
>> One question want to get some input from you guys: Do we need to
>> distinguish V2 and V3 API for this behavior? My thinking is that we do not
>> need to distinguish this for V2 and V3 API for the auto confirm feature,
>> the reason is as following:
>> 1) It is a new feature for Icehouse, for cold migration, Icehouse will
>> auto confirm all cold migration operations.
>> 2) We cannot know if the instance was cold migrated by V2 or V3, if
>> really want to distinguish, we may need to add some data in system metadata
>> to mark if the VM was cold migrated by V2 or V3 API.
>>
>>
> I think we do need to distinguish between the V2 and V3 API. Once
> released, the APIs have to remain stable in their behaviour even between
> openstack releases. So the behaviour for the V2 API has to remain the same
> otherwise we risk breaking existing applications which use the V2 API
> (which should not have to care if they are running against Havana or
> Icehouse).
>

@Chris, thanks for your comments. So do you have any comments for how we
can distinguish between the V2 and V3 API? My current thinking is perhaps
we can add some system metadata to do this.

>
>
>
>> Any comments?
>>
>> Thanks,
>>
>> Jay
>>
>>
>>
>> 2014/1/9 John Garbutt <john at johngarbutt.com>
>>
>>> On 8 January 2014 15:29, Jay Lau <jay.lau.513 at gmail.com> wrote:
>>> > 2014/1/8 John Garbutt <john at johngarbutt.com>
>>> >>
>>> >> On 8 January 2014 10:02, David Xie <david.scriptfan at gmail.com> wrote:
>>> >> > In nova/compute/api.py#2289, function resize, there's a parameter
>>> named
>>> >> > flavor_id, if it is None, it is considered as cold migration. Thus,
>>> nova
>>> >> > should skip resize verifying. However, it doesn't.
>>> >> >
>>> >> > Like Jay said, we should skip this step during cold migration, does
>>> it
>>> >> > make
>>> >> > sense?
>>> >>
>>> >> Not sure.
>>> >>
>>> >> > On Wed, Jan 8, 2014 at 5:52 PM, Jay Lau <jay.lau.513 at gmail.com>
>>> wrote:
>>> >> >>
>>> >> >> Greetings,
>>> >> >>
>>> >> >> I have a question related to cold migration.
>>> >> >>
>>> >> >> Now in OpenStack nova, we support live migration, cold migration
>>> and
>>> >> >> resize.
>>> >> >>
>>> >> >> For live migration, we do not need to confirm after live migration
>>> >> >> finished.
>>> >> >>
>>> >> >> For resize, we need to confirm, as we want to give end user an
>>> >> >> opportunity
>>> >> >> to rollback.
>>> >> >>
>>> >> >> The problem is cold migration, because cold migration and resize
>>> share
>>> >> >> same code path, so once I submit a cold migration request and
>>> after the
>>> >> >> cold
>>> >> >> migration finished, the VM will goes to verify_resize state, and I
>>> need
>>> >> >> to
>>> >> >> confirm resize. I felt a bit confused by this, why do I need to
>>> verify
>>> >> >> resize for a cold migration operation? Why not reset the VM to
>>> original
>>> >> >> state directly after cold migration?
>>> >>
>>> >> I think the idea was allow users/admins to check everything went OK,
>>> >> and only delete the original VM when the have confirmed the move went
>>> >> OK.
>>> >>
>>> >> I thought there was an auto_confirm setting. Maybe you want
>>> >> auto_confirm cold migrate, but not auto_confirm resize?
>>> >
>>> > [Jay] John, yes, that can also reach my goal. Now we only have
>>> > resize_confirm_window to handle auto confirm without considering it is
>>> > resize or cold migration.
>>> > # Automatically confirm resizes after N seconds. Set to 0 to
>>> > # disable. (integer value)
>>> > #resize_confirm_window=0
>>> >
>>> > Perhaps we can add another parameter say cold_migrate_confirm_window to
>>> > handle confirm for cold migration.
>>>
>>> I like Russell's suggestion, but maybe implement it as always doing
>>> auto_confirm for cold migrate in v3 API, and leaving it as is for
>>> resize.
>>>
>>> See if people like that, I should check with our ops guys.
>>>
>>> >> >> Also, I think that probably we need split compute.api.resize() to
>>> two
>>> >> >> apis: one is for resize and the other is for cold migrations.
>>> >> >>
>>> >> >> 1) The VM state can be either ACTIVE and STOPPED for a resize
>>> operation
>>> >> >> 2) The VM state must be STOPPED for a cold migrate operation.
>>> >>
>>> >> We just stop the VM them perform the migration.
>>> >> I don't think we need to require its stopped first.
>>> >> Am I missing something?
>>> >
>>> > [Jay] Yes, but just curious why someone want to cold migrate an ACTIVE
>>> VM?
>>> > They can use live migration instead and this can also make sure the VM
>>> > migrate seamlessly.
>>>
>>> If a disk is failing, people like to turn off the VMs to reduce load
>>> on that host while performing the migrations.
>>>
>>> And live-migrate (sadly) does not yet work in all configurations yet,
>>> so its useful where live-migrate is not possible.
>>>
>>> Also live-migrate with block_migration can use quite a lot more
>>> network bandwidth than cold migration, at least in the XenServer case.
>>>
>>> John
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/8958529f/attachment.html>