Open Stack

On 11/5/2019 2:11 PM, Albert Braden wrote:
> I found the offending UUID in the nova_api and placement databases. Do I 
> need to delete these entries from the DB or is there a safer way to get 
> rid of the “phantom” VM?
> 
> MariaDB [(none)]> select * from nova_api.instance_mappings where 
> instance_uuid = '4856d505-c220-4873-b881-836b5b75f7bb';
> 
> | created_at          | updated_at | id  | 
> instance_uuid                        | cell_id | 
> project_id                       | queued_for_delete |
> 
> | 2019-10-08 21:26:03 | NULL       | 589 | 
> 4856d505-c220-4873-b881-836b5b75f7bb |    NULL | 
> 474ae347d8ad426f8118e55eee47dcfd |                 0 |
> 

Interesting. So there is an instance mapping but it's not pointing at 
any cell. I'm assuming there is no entry for this instance in the 
nova_api.build_requests table either?

A couple of related patches for that instance mapping thing:

1. I have a patch that adds a nova-manage command to cleanup busted 
instance mappings [1]. In this case you'd just --purge that broken 
instance mapping.

2. mnaser has reported similar weird issues where an instance mapping 
exists but doesn't point at a cell and the build request is gone and the 
instance isn't in cell0. For that we have a sanity check patch [2] which 
might be helpful to you if you hit this again.

If either of those patches are helpful to you, please vote on the 
changes so we can draw some more eyes to the reviews.

As for the allocations, you can remove those from placement using the 
osc-placement CLI plugin [3]:

   openstack resource provider allocation delete 
4856d505-c220-4873-b881-836b5b75f7bb

[1] https://review.opendev.org/#/c/655908/
[2] https://review.opendev.org/#/c/683730/
[3] 
https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-allocation-delete

-- 

Thanks,

Matt