Open Stack

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 at 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