New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
baremetal IPI profile in install-config #2705
Comments
Thanks! I think the issue is setting the hardware profile to I'm not sure why the workers are ending up with the |
/label platform/baremetal |
@karmab Could you provide the information about the hardware in the install-config file you used, without the passwords to the BMC? I'm curious to see exactly how the data was passed to the installer. |
|
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'. So, in the TFvars, we map the string 'default' to 'unknown'. This was not done as part of the code that cares the baremetalhost object. This PR ensures the behavior is the same in both instances. fixes openshift#2705
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'. This was done since in golang code for the BMO, they're typically referring to `hardware.DefaultProfileName` directly. In the terraform vars, we map the string 'default' to 'hardware.DefaultProfileName`, but this was not done as part of the code that cares the baremetalhost resource. This PR ensures the behavior is the same in both instances. fixes openshift#2705
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 stuck 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. This PR ensures the behavior is the same in both instances, so you can use the string 'default' for workers and masters. fixes openshift#2705
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 stuck 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. This PR ensures the behavior is the same in both instances, so you can use the string 'default' for workers and masters. fixes openshift#2705
Version
Platform:
baremetal
What happened?
when trying to deploy workers along with the masters, i got the masters provisioned and the baremetal hosts objects associated to the workers created but not provisioned
removing hardware: profile from their spec triggered the install.
This seems to be caused by defaulting to "default" instead of the "unknown" profile
Enter text here.
See the troubleshooting documentation for ideas about what information to collect.
For example, if the installer fails to create resources, attach the relevant portions of your
.openshift_install.log
.What you expected to happen?
A deployment of my workers at install time
How to reproduce it (as minimally and precisely as possible)?
deploy with at least one worker
$ your-commands-here
Anything else we need to know?
Enter text here.
References
The text was updated successfully, but these errors were encountered: