> I'm contemplating how to fix > https://bugs.launchpad.net/nova/+bug/1339823 and it seems that a part of > the fix would be to track the state of live migrations in the database, > more or less the same way that cold migrations are tracked. The > thinking is that the logic could retrieve information about the live > migration (particularly its state) and act accordingly, again similar to > how incomplete cold migrations are handled during host initialization. > I have been looking through the relevant code history and I can't find > any information about why live migrations are not tracked in the > database while cold migrations are. In any case, before I start writing > a bunch of code, I was wondering whether others agree that tracking live > migrations in the database seems like a reasonable approach and if so, > whether existing Migration objects should be used for this purpose or if > a new type (e.g. LiveMigration) should be introduced instead.
There has been some effort and plans in the past to unify more than just the state tracking of live and cold migration. That effort is what needs to be done eventually. However, for your immediate bug, I say just have the compute host abandon the instance if the database says its host != self.host, and otherwise maybe just return it to a running state. I think it's fairly safe to say that if a live migration fails in the middle, there is little chance that it is running in a meaningful state on the source or destination host. As long as init_host() chooses a consistent way to determine ownership, that's *probably* the best we can do. --Dan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
