Re: [openstack-dev] [nova] Live migration objects
Dan, thank you for your reply. Regarding the following: 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. could you clarify what you mean by "abandon"? Would putting the instance in Error state be appropriate or did you have something else in mind? Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Live migration objects
> 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
[openstack-dev] [nova] Live migration objects
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. I'm thinking the former approach would entail adding a flag to the existing Migration type to indicate the migration type (cold vs. live); although arguably less invasive, using this approach might break existing functionality that retrieves migration information. Any guidance would be appreciated. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
