On 06/18/2018 08:16 AM, Artom Lifshitz wrote:
Hey all,
For Rocky I'm trying to get live migration to work properly for
instances that have a NUMA topology [1].
A question that came up on one of patches [2] is how to handle
resources claims on the destination, or indeed whether to handle that
at all.
I think getting the live migration to work at all is better than having it stay
broken, so even without resource claiming on the destination it's an improvement
over the status quo and I think it'd be a desirable change.
However, *not* doing resource claiming means that until the migration is
complete and the regular resource audit runs on the destination (which could be
a minute later by default) you could end up having other instances try to use
the same resources, causing various operations to fail. I think we'd want to
have a very clear notice in the release notes about the limitations if we go
this route.
I'm a little bit worried that waiting for support in placement will result in
"fully-functional" live migration with dedicated resources being punted out
indefinitely. One of the reasons why the spec[1] called for using the existing
resource tracker was that we don't expect placement to be functional for all
NUMA-related stuff for a while yet.
For what it's worth, I think the previous patch languished for a number of
reasons other than the complexity of the code...the original author left, the
coding style was a bit odd, there was an attempt to make it work even if the
source was an earlier version, etc. I think a fresh implementation would be
less complicated to review.
Given the above, my personal preference would be to merge it even without
claims, but then try to get the claims support merged as well. (Adding claims
support later on wouldn't change any on-the-wire messaging, it would just make
things work more robustly.)
Chris
[1]
https://github.com/openstack/nova-specs/blob/master/specs/rocky/approved/numa-aware-live-migration.rst
__________________________________________________________________________
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
