On Wed, Jan 22, 2014 at 1:05 PM, Jay Lau <[email protected]> wrote:
> > > > 2014/1/22 Christopher Yeoh <[email protected]> > >> On Mon, Jan 20, 2014 at 6:10 PM, Jay Lau <[email protected]> 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 <[email protected]> >>> >>>> On 8 January 2014 15:29, Jay Lau <[email protected]> wrote: >>>> > 2014/1/8 John Garbutt <[email protected]> >>>> >> >>>> >> On 8 January 2014 10:02, David Xie <[email protected]> >>>> 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 <[email protected]> >>>> 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 >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
