On Fri, 2014-01-17 at 09:39 -0800, Vishvananda Ishaya wrote: > > On Jan 16, 2014, at 9:41 PM, Jiang, Yunhong <[email protected]> > wrote: > > > I noticed the BP has been approved, but I really want to understand > > more on the reason, can anyone provide me some hints? > > > > In the BP, it states that “For resize, we need to confirm, as we > > want to give end user an opportunity to rollback”. But why do we > > want to give user an opportunity to rollback to resize? And why that > > reason does not apply to cold migration and live migration? > > > The confirm is so the user can verify that the instance is still > functional in the new state. We leave the old instance around so they > can abort and return to the old instance if something goes wrong. This > could apply to cold migration as well since it uses the same code > paths, but it definitely does not make sense in the case of > live-migration, because there is no old vm to revert to.
Thanks for clarification. > > In the case of cold migration, the state is quite confusing as > “RESIZE_VERIFY”, and the need to confirm is not immediately obvious so > I think that is driving the change. > I didn't saw patch to change the state in that BP, so possibly it's still on way. So basically the idea is, while we keep the implementation code path combined for resize/code migration as much as possible, but we will keep them different from user point of view, like different configuration option, different state etc, right? > --jyh _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
