Bug 1796996 - [IPI baremetal]: map "default" string in hardware profile to baremetal-operator default
Summary: [IPI baremetal]: map "default" string in hardware profile to baremetal-operat...
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 4.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.4.0
Assignee: Stephen Benjamin
QA Contact: Raviv Bar-Tal
Depends On:
Blocks: 1803187
TreeView+ depends on / blocked
Reported: 2020-01-31 17:27 UTC by Stephen Benjamin
Modified: 2020-05-13 21:56 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1803187 (view as bug list)
Last Closed: 2020-05-13 21:56:03 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift installer pull 2969 0 None closed Bug 1796996: baremetal: map hardware profile to baremetal-operator default 2020-09-29 07:27:28 UTC
Red Hat Product Errata RHBA-2020:0581 0 None None None 2020-05-13 21:56:05 UTC

Description Stephen Benjamin 2020-01-31 17:27:33 UTC
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

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

Comment 3 errata-xmlrpc 2020-05-13 21:56:03 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.


Note You need to log in before you can comment on or make changes to this bug.