On Tue, Jun 19, 2018 at 9:59 PM, Artom Lifshitz <alifs...@redhat.com> wrote:
> > Adding > > claims support later on wouldn't change any on-the-wire messaging, it > would > > just make things work more robustly. > > I'm not even sure about that. Assuming [1] has at least the right > idea, it looks like it's an either-or kind of thing: either we use > resource tracker claims and get the new instance NUMA topology that > way, or do what was in the spec and have the dest send it to the > source. > > That being said, I still think I'm still in favor of choosing the > "easy" way out. For instance, [2] should fail because we can't access > the api db from the compute node. So unless there's a simpler way, > using RT claims would involve changing the RPC to add parameters to > check_can_live_migration_destination, which, while not necessarily > bad, seems like useless complexity for a thing we know will get ripped > out. > > When we reviewed the spec, we agreed as a community to say that we should still get race conditions once the series is implemented, but at least it helps operators. Quoting : "It would also be possible for another instance to steal NUMA resources from a live migrated instance before the latter’s destination compute host has a chance to claim them. Until NUMA resource providers are implemented [3] <https://review.openstack.org/#/c/552924/> and allow for an essentially atomic schedule+claim operation, scheduling and claiming will keep being done at different times on different nodes. Thus, the potential for races will continue to exist." https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html#proposed-change So, my own opinion is that yes, the "easy" way out is better than no way. >From what I undertand (and let's be honest I hadn't time to look at your code yet), your series don't diverge from the proposed implementation so I don't see a problem here. If, for some reasons, you need to write an alternative, just tell us why (and ideally write a spec amendment patch so the spec is consistent with the series). -Sylvain [1] https://review.openstack.org/#/c/576222/ > [2] https://review.openstack.org/#/c/576222/3/nova/compute/manager.py@5897 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
