Bug 1803187

Summary:	[IPI baremetal]: map "default" string in hardware profile to baremetal-operator default
Product:	OpenShift Container Platform	Reporter:	Stephen Benjamin <stbenjam>
Component:	Installer	Assignee:	Stephen Benjamin <stbenjam>
Installer sub component:	OpenShift on Bare Metal IPI	QA Contact:	Amit Ugol <augol>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	mcornea, rbartal
Version:	4.4
Target Milestone:	---
Target Release:	4.3.z
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1796996	Environment:
Last Closed:	2020-03-10 23:53:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1796996
Bug Blocks:

Description Stephen Benjamin 2020-02-14 16:05:56 UTC

+++ This bug was initially created as a clone of Bug #1796996 +++

We rely on vendored baremetal-operator code to handle various
information about baremetal servers including BMC credentials and
hardware profiles. The BMO uses the string 'unknown' as
hardware.DefaultProfileName.

As these string values are exposed to the user in the baremetal platform
as part of the install-config, it felt awkward if a user wanted to
explicitly use the default hardware profile to have to write the string
'unknown'. In golang, people are generally just writing the constant,
'hardware.DefaultProfileName`. So, in the terraform variables, we mapped
the string value 'default' to mean that, but it wasn't done for creating
the machines for workers.

Now that you can deploy workers during installation as a day-1
operation, if you specify the string 'default' for workers, they get
stuck in the 'match profile' state of the BMO. Keep in mind, these
baremetalhosts are all defined in the 'hosts' section of the install
config, but the profiles are now working differently depending on
whether it's part of the control plane (i.e. created by terraform) or
not.

Comment 3 Marius Cornea 2020-03-03 16:58:00 UTC

version   4.3.0-0.nightly-2020-03-01-194304   True        False         34s     Cluster version is 4.3.0-0.nightly-2020-03-01-194304


Verified on bare metal installation with:

    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: ipmi://[fd2e:6f44:5dd8:c956::1]:6230
          username: admin
          password: password
        bootMACAddress: 52:54:00:f7:4b:18
        hardwareProfile: default
      - name: openshift-master-1
        role: master
        bmc:
          address: ipmi://[fd2e:6f44:5dd8:c956::1]:6231
          username: admin
          password: password
        bootMACAddress: 52:54:00:4e:98:a4
        hardwareProfile: default
      - name: openshift-master-2
        role: master
        bmc:
          address: ipmi://[fd2e:6f44:5dd8:c956::1]:6232
          username: admin
          password: password
        bootMACAddress: 52:54:00:42:b9:a3
        hardwareProfile: default
      - name: openshift-worker-0
        role: worker
        bmc:
          address: ipmi://[fd2e:6f44:5dd8:c956::1]:6233
          username: admin
          password: password
        bootMACAddress: 52:54:00:23:5c:3f
        hardwareProfile: default
      - name: openshift-worker-1
        role: worker
        bmc:
          address: ipmi://[fd2e:6f44:5dd8:c956::1]:6234
          username: admin
          password: password
        bootMACAddress: 52:54:00:ef:d6:1d
        hardwareProfile: default

Comment 5 errata-xmlrpc 2020-03-10 23:53:52 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0676