Interesting, I tried to reproduce it on latest master with a two node devstack and evacuate worked with affinity or anti-affinity group after the group was deleted.
We does not store the group uuid on the instance but store the instance_uuid in the group so when the group is deleted there should be no way to found that group based on the instance_uuid.
This is the place where the scheduler gets the group, if any, for the instance being scheduled [1].
We also store the group uuid in the RequestSpec but loading a RequestSpec back from the DB also guarded against deleted groups. [2]
Could you execute
$openstack server group show <grp>
before you delete the group?
Could you also grep the nova logs for with the group uuid to see if any interesting log shows up?
Interesting, I tried to reproduce it on latest master with a two node devstack and evacuate worked with affinity or anti-affinity group after the group was deleted.
We does not store the group uuid on the instance but store the instance_uuid in the group so when the group is deleted there should be no way to found that group based on the instance_uuid.
This is the place where the scheduler gets the group, if any, for the instance being scheduled [1].
We also store the group uuid in the RequestSpec but loading a RequestSpec back from the DB also guarded against deleted groups. [2]
Could you execute
$openstack server group show <grp>
before you delete the group?
Could you also grep the nova logs for with the group uuid to see if any interesting log shows up?
[1] https:/ /github. com/openstack/ nova/blob/ 8ecc29bfccc64e6 036d068f9bcbeb0 d8e0748776/ nova/scheduler/ utils.py# L1076
[2] https:/ /github. com/openstack/ nova/blob/ 8ecc29bfccc64e6 036d068f9bcbeb0 d8e0748776/ nova/objects/ request_ spec.py# L595