Bug 1956714

Summary: Machines stuck in Provisioning state due to missing 'providerID' - IPI Baremetal Installation
Product: OpenShift Container Platform Reporter: Kaushal Sathe <ksathe>
Component: assisted-installerAssignee: Ronnie Lazar <alazar>
assisted-installer sub component: assisted-service QA Contact: Yuri Obshansky <yobshans>
Status: CLOSED NOTABUG Docs Contact:
Severity: medium    
Priority: medium CC: alazar, aos-bugs, asalkeld, beth.white, jkaur, rfreiman, tsedovic, zbitter
Version: 4.6.zKeywords: Triaged
Target Milestone: ---   
Target Release: 4.8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-12 21:14:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Comment 2 Zane Bitter 2021-05-04 17:40:12 UTC
I'm not sure what has happened here; this looks like a cluster that has been cobbled together manually, although the reproduction instructions appear to indicate that is not the case?

- metal3 is not running (the Deployment does not exist)
- master BareMetalHosts still have paused annotations, as if the installation never finished
- no attempt has been made to provision the worker BareMetalHosts, although they have inspection data (presumably added by the installer?)

I think the Machines are failing to pick up any BareMetalHosts because they have an empty provisioning status (due to metal3 not running to reconcile them). So the warnings are correct. 2 worker Nodes are up and ready, but I'm not sure what provisioned them. It doesn't appear to be the Machines.