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:
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:
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.
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/ e3c24da89aa3e64 62f1b07e00659c8 7f252ba4ba/ nova/compute/ resource_ tracker. py#L1048- L1073
The key part is this:
https:/ /github. com/openstack/ nova/blob/ e3c24da89aa3e64 62f1b07e00659c8 7f252ba4ba/ 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/ e3c24da89aa3e64 62f1b07e00659c8 7f252ba4ba/ 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 I036a5ceabe88dc c1fd85c09472481 de7d02edf5f in stable/ocata (without placement in the scheduler) or maybe even mitaka.