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