Hi Matt, I did in the DB directly. I am using queens now. Any python client command to delete hold records or I must use api ? Thanks & Regards Ignazio Il giorno gio 29 nov 2018 alle ore 16:28 Matt Riedemann <mriedemos@gmail.com> ha scritto:
On 11/29/2018 12:49 AM, Ignazio Cassano wrote:
Hello Mattm Yes I mean sometimes I have same host/node names with different uuid in compute_nodes table in nova database I must delete nodes with uuid those not match with nova-hypervisor list command. At this time I have the following: MariaDB [nova]> select hypervisor_hostname,uuid,deleted from compute_nodes; +---------------------+--------------------------------------+---------+ | hypervisor_hostname | uuid | deleted | +---------------------+--------------------------------------+---------+ | tst2-kvm02 | 802b21c2-11fb-4426-86b9-bf25c8a5ae1d | 0 | | tst2-kvm01 | ce27803b-06cd-44a7-b927-1fa42c813b0f | 0 | +---------------------+--------------------------------------+---------+ 2 rows in set (0,00 sec)
But sometimes old uuid are inserted in the table . I deleted again them. I restarted kvm nodes and now the table is ok. I also restarded each controller and the tables is ok. I do not know because 3 days ago I had same compute nodes names with different uuids.
Thanks and Regards Ignazio
OK I guess if it happens again, please get the host/hypervisor_hostname/uuid/deleted values from the compute_nodes table before you cleanup any entries.
Also, when you're deleting the resources from the DB, are you doing it in the DB directly or via the DELETE /os-services/{service_id} API? Because the latter cleans up other related resources to the nova-compute service (the services table record, the compute_nodes table record, the related resource_providers table record in placement, and the host_mappings table record in the nova API DB). The resource provider/host mappings cleanup when deleting a compute service is a more recent bug fix though which depending on your release you might not have:
https://review.openstack.org/#/q/I7b8622b178d5043ed1556d7bdceaf60f47e5ac80
--
Thanks,
Matt