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.
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:0581