Description of problem: While baremetal operator is trying to adopt externally provisioned bmh, it is trying to validate the image against the image checksum. BMO should not do it, as externally provisioned hosts should not be provisioned with any image. Version-Release number of selected component (if applicable): 4.5 Steps to Reproduce: 1. create bmh CR with image and image checksum url that doesn't exist and with externallyProvisioned: true 2. wait until error appears in oc get bmh Actual results: Error, e.g.: Host adoption failed: Error while attempting to adopt node 64f7d62b-db72-431a-8f5e-2dfa2ce75553: Validation of image href http://172.22.0.3:6180/images/rhcos-44.81.202004250133-0-openstack.x86_64.qcow2/rhcos-44.81.202004250133-0-compressed.x86_64.qcow2 failed, reason: HTTPConnectionPool(host='172.22.0.3', port=6180): Max retries exceeded with url: /images/rhcos-44.81.202004250133-0-openstack.x86_64.qcow2/rhcos-44.81.202004250133-0-compressed.x86_64.qcow2 (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f15ddccb780>: Failed to establish a new connection: [Errno 110] ETIMEDOUT',)). Expected results: No error, and host will be in externally provisioned state
You shouldn't specify any image when using externallyProvisioned: true - it should be left empty, do we have some docs somewhere saying to add dummy data? Perhaps the BMO should ignore the data (or, ideally reject the BMH definition as invalid), but I want to clarify if this is a corner case or if we have some docs/automation doing the wrong thing?
Thanks. That makes sense. Perhaps it worth adding some note in externallyProvisioned or in image section? https://github.com/metal3-io/baremetal-operator/blob/master/docs/api.md
The image setting is necessary in order for Ironic to consider the host in a state where it will monitor the power state. I have some work in progress to update the baremetal-operator so it waits to register the host with Ironic until after the image details are provided, so the error message explains what is wrong in terms that a metal3 user will understand. https://github.com/metal3-io/baremetal-operator/pull/609 It would also be useful to consider changes in Ironic to allow it to monitor the power of a host even if the host cannot be reprovisioned if there is some sort of failure.
That pull request is linked to https://bugzilla.redhat.com/show_bug.cgi?id=1864327
(In reply to Steven Hardy from comment #1) > You shouldn't specify any image when using externallyProvisioned: true - it > should be left empty, do we have some docs somewhere saying to add dummy > data? > > Perhaps the BMO should ignore the data (or, ideally reject the BMH > definition as invalid), but I want to clarify if this is a corner case or if > we have some docs/automation doing the wrong thing? The IPI installer creates the control plane hosts without image details, but after the cluster forms they do have those settings. I think CAPBM is updating the image details when it links the host and machine resources for the control plane. As far as I can tell, we never see an error because it takes far longer for the metal3 pod to start than CAPBM, so CAPBM is always winning the race today.