This is split off from bug 1829479 which is about deleting a compute service which had servers evacuated from it which will orphan resource providers in placement.
A similar scenario is true where the API will allow deleting a source compute service which has migration-based allocations for the source node resource provider and pending instance resizes involving the source node. A simple scenario is:
1. create a server on host1
2. resize or cold migrate it to a dest host2
3. delete the compute service for host1
At this point the resource provider for host1 is orphaned.
4. try to confirm/revert the resize of the server which will fail because the compute node for host1 is gone and this results in the server going to ERROR status
Based on the discussion in this mailing list thread:
This is split off from bug 1829479 which is about deleting a compute service which had servers evacuated from it which will orphan resource providers in placement.
A similar scenario is true where the API will allow deleting a source compute service which has migration-based allocations for the source node resource provider and pending instance resizes involving the source node. A simple scenario is:
1. create a server on host1
2. resize or cold migrate it to a dest host2
3. delete the compute service for host1
At this point the resource provider for host1 is orphaned.
4. try to confirm/revert the resize of the server which will fail because the compute node for host1 is gone and this results in the server going to ERROR status
Based on the discussion in this mailing list thread:
http:// lists.openstack .org/pipermail/ openstack- discuss/ 2019-November/ 010843. html
We should probably have the DELETE /os-services/ {service_ id} API block trying to delete a service that has pending migrations.