The line
2021-06-11 14:45:49.829 959 INFO masakari.api.openstack.wsgi [req-e9a58522-858d-4025-9c43-f9fee744a0db nova - - - -] HTTP exception thrown: Compute service with name XXXXX could not be found.
suggests that nova actively disagrees that this compute node actually exists. As for the exercised behaviour: this is tested both in Masakari and Kolla Ansible CIs, and it works. I am afraid the answer to why this fails lies in the format of that hidden XXXXX. At the moment, I can't really think of how that could affect the outcome. Is XXXXX 100% the same between the different logs? If you can't somehow share how XXXXX looks, then you might want to check the Nova API logs (again, debug=True might help a bit) and compare between how the openstack client query works vs how the Masakari query works. Perhaps, there is a glitch at some stage that causes the XXXXX to get garbled. You can also append --debug to the openstack commands to get the client side of the conversation. On Fri, Jun 11, 2021 at 5:10 PM bkslash <bkslash@poczta.onet.pl> wrote:
openstack compute service list --service nova-compute --host $HOSTNAME did you try including the same hostname in this command? yes, and it returns the same as "openstack compute service list" but of course only for host XXXXX
If it works and Masakari does not, I would make sure you set up Masakari to speak to the right Nova API. I'm using kolla-ansible, all masakari configuration was generated based on globals.yaml and inventory file while deployment, so it should work almost "out of the box". Does masakari speak to nova via RabbitMQ? How else can I check which port/IP masakari speaks to? In logs I can only see requests TO masakari API, not where masakari tries to check hypervisor...
Masakari speaks to Nova via Nova API only. If you used Kolla Ansible, then it's set up correctly unless you manually overrode that. By default, Masakari looks up the Nova endpoint from the Keystone catalogue. -yoctozepto