Skip to content
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

Closed
karmab opened this issue Nov 21, 2019 · 4 comments · Fixed by #2969
Closed

baremetal IPI profile in install-config #2705

karmab opened this issue Nov 21, 2019 · 4 comments · Fixed by #2969
Labels
platform/baremetal IPI bare metal hosts platform

Comments

@karmab
Copy link
Contributor

karmab commented Nov 21, 2019

Version

$ openshift-install version
./openshift-baremetal-install unreleased-master-2170-ga702fd4beb593932067fe1b31f2d911feaa6d93e
built from commit a702fd4beb593932067fe1b31f2d911feaa6d93e
release image registry.svc.ci.openshift.org/origin/release:4.3

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

  • enter text here.
@stbenjam
Copy link
Member

Thanks!

I think the issue is setting the hardware profile to default, where the BMO uses the name unknown. The way I handled this wasn't super well thought through in the installer: https://github.com/openshift/installer/blob/master/pkg/tfvars/baremetal/baremetal.go#L43-L45

I'm not sure why the workers are ending up with the default profile, though. Need to track that down.

@stbenjam
Copy link
Member

/label platform/baremetal

@openshift-ci-robot openshift-ci-robot added the platform/baremetal IPI bare metal hosts platform label Nov 21, 2019
@dhellmann
Copy link
Contributor

@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.

@karmab
Copy link
Contributor Author

karmab commented Nov 22, 2019

apiVersion: v1
baseDomain: karmalabs.com
networking:
  machineCIDR: 192.168.120.0/24
metadata:
  name: doug
compute:
- name: worker
  replicas: 2
controlPlane:
  name: master
  replicas: 1
  platform:
    baremetal: {}
platform:
  baremetal:
    apiVIP: 192.168.120.100
    dnsVIP: 192.168.120.101
    ingressVIP: 192.168.120.102
    provisioningBridge: provisioning
    externalBridge: baremetal
    libvirtURI: qemu+ssh://root@192.168.120.1/system
    hosts:
      - name: openshift-master-0
        role: master
        bmc:
          address: ipmi://192.168.121.1
          username: root
          password: jmayer
        bootMACAddress: 98:03:9b:61:80:48
        hardwareProfile: default
      - name: openshift-worker-1
        role: worker
        bmc:
          address: ipmi://192.168.121.2
          username: root
          password: eclapton
        hardwareProfile: default
        bootMACAddress: 98:03:9b:61:ae:18
      - name: openshift-worker-2
        role: worker
        bmc:
          address: ipmi://192.168.121.3
          username: root
          password: jhendrix
        bootMACAddress: 98:03:9b:61:ba:d0
        hardwareProfile: default
pullSecret: |
  XXX
sshKey: |
  XXX

stbenjam added a commit to stbenjam/installer that referenced this issue Jan 23, 2020
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
stbenjam added a commit to stbenjam/installer that referenced this issue Jan 23, 2020
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
stbenjam added a commit to stbenjam/installer that referenced this issue Jan 23, 2020
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
openshift-cherrypick-robot pushed a commit to openshift-cherrypick-robot/installer that referenced this issue Feb 14, 2020
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform/baremetal IPI bare metal hosts platform
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants