<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 14, 2022 at 9:40 PM Laurent Dumont <<a href="mailto:laurentfdumont@gmail.com">laurentfdumont@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">From what I understand of baremetal nodes, they will show up as hypervisors from the Nova perspective.<div><br></div><div>Can you try "openstack hypervisor list"</div><div><br></div><div>From the doc </div><div><br></div></div></blockquote><div><br></div><div>+1. This is a good idea. This will tell us if Nova is at least syncing with Ironic. If it can't push the information to placement, that is obviously going to cause issues.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><div style="box-sizing:border-box;font-size:11.9px;background:rgb(237,242,247);color:rgb(42,78,104);border-width:1px 1px 1px 4px;border-style:solid;border-color:rgb(42,78,104);padding:15px;margin:15px 0px;border-radius:4px;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif"><p style="box-sizing:border-box;margin:0px 0px 10px;font-size:inherit">Each bare metal node becomes a separate hypervisor in Nova. The hypervisor host name always matches the associated node UUID.</p></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 14, 2022 at 10:03 AM Lokendra Rathour <<a href="mailto:lokendrarathour@gmail.com" target="_blank">lokendrarathour@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Julia,<div>Thanks once again. we got your point and understood the issue, but we still are facing the same issue on our TRIPLEO Train HA Setup, even if the settings are done as per your recommendations.</div><div><br></div><div>The error that we are seeing is  again "<b>No valid host was found"</b></div><div><b><br></b></div><div><br></div></div></blockquote></div></blockquote><div><br></div><div><br></div><div>So this error is a bit of a generic catch error indicating it just doesn't know how to schedule the node. But the next error you mentioned *is* telling in that a node can't be scheduled if placement is not working.</div><div><br></div><div>[trim]</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>On further debugging, we found that in the nova-scheduler logs :</div><div><b><br>2022-02-14 12:58:22.830 7 WARNING keystoneauth.discover [-] Failed to contact the endpoint at <a href="http://172.16.2.224:8778/placement" target="_blank">http://172.16.2.224:8778/placement</a> for discovery. Fallback to using that endpoint as the base url.<br>2022-02-14 12:58:23.438 7 WARNING keystoneauth.discover [req-ad5801e4-efd7-4159-a601-68e72c0d651f - - - - -] Failed to contact the endpoint at <a href="http://172.16.2.224:8778/placement" target="_blank">http://172.16.2.224:8778/placement</a> for discovery. Fallback to using that endpoint as the base url.</b><br></div><div><br></div><div>where 172.16.2.224 is the internal IP. </div><div><br></div><div>going by document :</div><div><a href="https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/baremetal_overcloud.html" target="_blank">Bare Metal Instances in Overcloud — TripleO 3.0.0 documentation (openstack.org)</a><br></div><div><br></div><div>it is given as below for commands:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>(overcloud) [root@overcloud-controller-0 ~]# endpoint=<a href="http://172.16.2.224:8778/placement" target="_blank">http://172.16.2.224:8778/placement</a></div><div>(overcloud) [root@overcloud-controller-0 ~]# token=$(openstack token issue -f value -c id)</div><div>(overcloud) [root@overcloud-controller-0 ~]# curl -sH "X-Auth-Token: $token" $endpoint/resource_providers/<node id> | jq .inventories</div><div><b>null</b></div></blockquote><div>result is the same even if we run the curl command on public endpoint.<br></div><div><br></div><div>Please advice. </div><div><br></div></div></blockquote></div></blockquote><div><br></div><div>So this sounds like you have placement either not operating or incorrectly configured somehow. I am not a placement expert, but I don't think a node_id is used for resource providers.</div><div><br></div><div>Hopefully a placement expert can chime in here. That being said, the note about the service failing to connect to the endpoint for discovery is somewhat telling. You *should* be able to curl the root of the API, without a token, and discover a basic JSON document response with information which is used for API discovery. If that is not working, then there may be several things occuring. I would check to make sure the container(s) running placement are operating, not logging any errors, and responding properly. If they are responding if directly queried, then I wonder if there is something going on with load balancing. Possibly consider connecting to placement's port directly instead of through any sort of load balancing such as what is provided by haproxy. I think placement's log indicates the port it starts on, so that would hopefully help. It's configuration should also share the information as well. </div></div></div>