The logic here [0] indeed seems to be incorrect, eg in case of there is
a node in available state with instance_uuid set, first the driver will
report vcpus=vcpus_used=properties['vcpus'] and then will set vcpus=0
leaving vcpus_used intact.
My proposal here is the following:
* If there is an instance_uuid on the node, no matter what provision/power
state it's in, consider the resources as used. In case it's an orphan,
an admin will need to take some manual action anyway.
* If there is no instance_uuid and a node is in cleaning/clean wait after
tear down, it is a part of normal node lifecycle, report all resources
as used. This means we need a way to determine if it's a manual or
automated clean.
* If there is no instance_uuid, and a node:
- has a bad power state or
- is in maintenance
- manual clean is happening
or actually in any other case, consider it unavailable, report available
resources = used resources = 0. Provision state does not matter in this
logic, all cases that we wanted to take into account are described in
the first two bullets.
The logic here [0] indeed seems to be incorrect, eg in case of there is used=properties ['vcpus' ] and then will set vcpus=0
a node in available state with instance_uuid set, first the driver will
report vcpus=vcpus_
leaving vcpus_used intact.
My proposal here is the following:
* If there is an instance_uuid on the node, no matter what provision/power
state it's in, consider the resources as used. In case it's an orphan,
an admin will need to take some manual action anyway.
* If there is no instance_uuid and a node is in cleaning/clean wait after
tear down, it is a part of normal node lifecycle, report all resources
as used. This means we need a way to determine if it's a manual or
automated clean.
* If there is no instance_uuid, and a node:
- has a bad power state or
- is in maintenance
- manual clean is happening
or actually in any other case, consider it unavailable, report available
resources = used resources = 0. Provision state does not matter in this
logic, all cases that we wanted to take into account are described in
the first two bullets.
[0] https:/ /github. com/openstack/ nova/blob/ 1506c36b4446f6b a1487a2d68e4b23 cb3fca44cb/ nova/virt/ ironic/ driver. py#L262