[Openstack-operators] Fwd: Nova hypervisor uuid

Matt Riedemann mriedemos at gmail.com
Thu Nov 29 15:28:46 UTC 2018


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



More information about the OpenStack-operators mailing list