So I'm a big ol' -0- don't care on this. We've never used that list before (but will now). Seems like it would be useful though to have it the same for l-m and cold migration.
On Wed, May 11, 2016 at 9:27 AM, Andrew Laski <and...@lascii.com> wrote: > > > > On Wed, May 11, 2016, at 11:10 AM, David Medberry wrote: > > Kekane, > > Hi, > > This setting, how does it display in the "nova show $UUID" or in the > "openstack server show $UUID"? Ie, I don't want a VM showing ERROR state if > the VM itself is not in error. A failed migration doesn't leave the VM down > (well, not always) but error generally implies it is down. If this is more > of an internal status, then +1. I'll look at the code shortly but wanted to > get a reply off first. > > > To clarify, this is only about the state of a migration not an instance. > If as an admin you list or show your migrations this would affect how that > is displayed. Nothing about the instance, or how it's displayed, will > change. > > > > > ALSO: It would have been very very helpful to see "live-migration" in the > subject line. > > > -d > > On Wed, May 11, 2016 at 12:55 AM, Kekane, Abhishek < > abhishek.kek...@nttdata.com> wrote: > > Hi Operators, > > > > Could you please provide your opinion on below mail. I need to discuss > this in coming nova meeting (12 May, 2016). > > > > Thank you, > > > > Abhishek Kekane > > > > *From:* Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] > *Sent:* Monday, May 09, 2016 7:22 AM > *To:* openstack-operators@lists.openstack.org > *Subject:* [Openstack-operators] [Nova] Significance of Error Vs Failed > status > > > > Hi All, > > In Liberty release, we had upstream [1] a security fix to cleanup orphaned > instance files from compute nodes for resize operation. To fix this > security issue, a new periodic task '_cleanup_incomplete_migrations’ was > introduced that runs on each compute node which queries for deleted > instances and migration status in “error” status. If there are any such > instances, then it simply cleanup instance files on that particular compute > node. > > Similar issue is reported in LP bug [2] for Live-migration operation and > we would like to use the same periodic task to fix this problem. But in > case of live migration, the migration status is set to “failed” instead of > “error” status if migration fails for any reason. This change was > introduced in patch [3] when migration object support was added for live > migration. Due to this inconsistency, the periodic task will not pickup > instances to cleanup orphaned instance files. To fix this problem, we > simply want to set the migration status to “error” in patch [4] same as > done for resize operation to bring consistency to the code. > > We have discussed about this issue in the nova meeting [5] and decided > that to the client, migration status 'error' vs. 'failed' should be > considered the same thing, it's a failure. From operators point of view, is > there any significance of setting migration status to 'error' or 'failed', > if yes what is it and what impact it will have if migration status is > changed from 'failed' to 'error'. Please provide your opinions on the same. > > > > [1] https://review.openstack.org/#/c/219299 > > [2] : https://bugs.launchpad.net/nova/+bug/1470420 > > [3] https://review.openstack.org/#/c/183331 > > [4] https://review.openstack.org/#/c/215483 > > [5] > http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2016-05-05.log.html#t2016-05-05T14:40:51 > > Thank You, > > Abhishek > > > > ______________________________________________________________________ > Disclaimer: This email and any attachments are sent in strictest confidence > for the sole use of the addressee and may contain legally privileged, > confidential, and proprietary data. If you are not the intended recipient, > please advise the sender by replying promptly to this email and then delete > and destroy this email and any attachments without any further use, copying > or forwarding. > > > > ______________________________________________________________________ > Disclaimer: This email and any attachments are sent in strictest confidence > for the sole use of the addressee and may contain legally privileged, > confidential, and proprietary data. If you are not the intended recipient, > please advise the sender by replying promptly to this email and then delete > and destroy this email and any attachments without any further use, copying > or forwarding. > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > *_______________________________________________* > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
