Open Stack

On Wed, Jan 22, 2014 at 1:05 PM, Jay Lau <jay.lau.513 at gmail.com> wrote:

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

Yea I think that should be fine.


>
>>
>>> 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
>>
>>
>
> _______________________________________________
> 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/798f6888/attachment.html>