Open Stack

On 1/22/2019 12:19 PM, Sean Mooney wrote:
> you are specifically doing a resize so you dont need to regenerate a new xml
> on the source node before starting a live migration sice its not a live migration
> but you might want to premtpvily allcoate the pci devices on the destination
> if you want to prevent a race with other hosts. That said for stien it may be better
> to declare that out of scope. its really not any more racy then spawning an instace
> as we dont claim the device untill we get to the compute node anyway today.

Correct, and the plan for cross-cell resize is to do the same 
RT.resize_claim on the target host in the target cell before trying to 
move anything, which is the same thing we do in 
ComputeManager.prep_resize for a normal resize within the same cell.

> 
> the instance.numa_topology shoudl really be recalulated for the target host also.
> you do not want to require the destination host to place the vm with the original
> numa toptolgy from the source node. so i think you need to propagate the numa related
> request which are all in the flavor/image but i dont think you need to copy
> the instance numa_topology object. its not a live migration so provided the

The instance.numa_topology is calculated from the flavor and image 
during the initial server create:

https://github.com/openstack/nova/blob/dd84e75260c3c919398536f7d05764713dc1c8cd/nova/compute/api.py#L799

And during the MoveClaim:

https://github.com/openstack/nova/blob/dd84e75260c3c919398536f7d05764713dc1c8cd/nova/compute/claims.py#L294

So yeah it looks like I don't really have to worry about 
updating/setting instance.numa_topology in the target cell DB during the 
resize although it seems pretty weird that we leave that stale 
information in the instances table during a resize (it's also stale in 
the RequestSpec - I think Alex Xu reported a bug for that).

-- 

Thanks,

Matt