Comment 12 for bug 1790204

For my own notes, I was wondering how the ResourceTracker claims code in the nova-compute service handles a same-host resize (before placement) and this is the code that calculates the usage for same-host resize during the resize_claim on the host:

https://github.com/openstack/nova/blob/e3c24da89aa3e6462f1b07e00659c87f252ba4ba/nova/compute/resource_tracker.py#L1048-L1073

The key part is this:

https://github.com/openstack/nova/blob/e3c24da89aa3e6462f1b07e00659c87f252ba4ba/nova/compute/resource_tracker.py#L1053

Which means usage for that instance on that host is reported using the new_flavor only, however, during the update_available_resource periodic task if the instance has already been resized and is sitting in 'VERIFY_RESIZE' status the old_flavor will also be accounted:

https://github.com/openstack/nova/blob/e3c24da89aa3e6462f1b07e00659c87f252ba4ba/nova/compute/resource_tracker.py#L1070

Which means, essentially, the resource tracker claims code would also "double up" the resource usage from both flavors on the same host, which could over-commit that host and make the scheduler ignore it for scheduling new instances even though it's not really at capacity - thus making this a latent issue (not a regression in Pike when the scheduler started creating allocations in placement). To be sure, I'd need to run the functional regression test from I036a5ceabe88dcc1fd85c09472481de7d02edf5f in stable/ocata (without placement in the scheduler) or maybe even mitaka.