Bug 2082671 - [IPI baremetal] expanding cluster docs networkConfig BareMetalHost syntax is wrong
Summary: [IPI baremetal] expanding cluster docs networkConfig BareMetalHost syntax is ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 4.10
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: avbhatt
QA Contact: Adina Wolff
Tomas 'Sheldon' Radej
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-06 17:56 UTC by Nikos Stamatelopoulos
Modified: 2022-06-14 15:24 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-14 15:24:37 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Nikos Stamatelopoulos 2022-05-06 17:56:45 UTC
Document URL: https://docs.openshift.com/container-platform/4.10/installing/installing_bare_metal_ipi/ipi-install-expanding-the-cluster.html

Section Number and Name: https://docs.openshift.com/container-platform/4.10/installing/installing_bare_metal_ipi/ipi-install-expanding-the-cluster.html

Describe the issue: In the "Preparing the bare metal node" section of the above documentation there is Baremetalhost definition file that includes the section "networkConfig".

~~~
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: openshift-worker-<num> 
spec:
  online: true
  bootMACAddress: <NIC1-mac-address> 
  bmc:
    address: <protocol>://<bmc-ip> 
    credentialsName: openshift-worker-<num>-bmc-secret 
  networkConfig:                              <------------------
    interfaces:
    - name: <NIC1_name>
      type: ethernet
      state: up
      ipv4:
        address:
        - ip: "<IP_address>"
          prefix-length: 24
        enabled: true
    dns-resolver:
      config:
        server:
        - <DNS_IP_address>
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: <IP_address>
        next-hop-interface: <NIC1_name>
~~~

This is not valid as it is not included in the API reference documentation page:

https://docs.openshift.com/container-platform/4.10/rest_api/provisioning_apis/baremetalhost-metal3-io-v1alpha1.html

Or at the latest version oc client:

~~~
[nstamate@nstamate ~]$ oc version
Client Version: 4.10.12
Server Version: 4.10.8
Kubernetes Version: v1.23.5+1f952b3
[nstamate@nstamate ~]$ oc explain baremetalhost.spec
KIND:     BareMetalHost
VERSION:  metal3.io/v1alpha1

RESOURCE: spec <Object>

DESCRIPTION:
     BareMetalHostSpec defines the desired state of BareMetalHost

FIELDS:
   ------------------ trimmed output -----------------------------------
   metaData	<Object>
     MetaData holds the reference to the Secret containing host metadata (e.g.
     meta_data.json) which is passed to the Config Drive.

   networkData	<Object>
     NetworkData holds the reference to the Secret containing network
     configuration (e.g content of network_data.json) which is passed to the
     Config Drive.

   online	<boolean> -required-
     Should the server be online?

   ------------------ trimmed output -----------------------------------

The only way to configure the bare metal node's networking during provisioning is using the "networkData" object or using "networkConfig" during installation fo the cluster AFAIK or correct me if I'm wrong.

Suggestions for improvement: 

This section should be removed/corrected as it is misleading customers. 

Additional information: 

This was found during the investigation of the attached case.

Comment 1 Nikos Stamatelopoulos 2022-05-23 12:44:03 UTC
Hello again,

After internal communication I should add in this bug that the networkData is not the correct way to do this either.

The administrator should add the spec.preprovisioningNetworkDataName object and reference a secret that includes the network configuration in nmstate format like below:

~~~
apiVersion: v1
kind: Secret
metadata:
  name: new-worker-network-config
  type: Opaque
stringData:
  nmstate: |
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: 192.168.123.1
        next-hop-interface: enp0s4
    dns-resolver:
      config:
        server:
        - 192.168.123.1
    interfaces:
    - name: enp0s4
      state: up
      ipv4:
        address:
        - ip: 192.168.123.11
          prefix-length: 24
        enabled: true
        dhcp: false
---
apiVersion: v1
kind: Secret
metadata:
  name: openshift-worker-bmc-secret
  namespace: openshift-machine-api
type: Opaque
data:
  username: <base64-formated-username>
  password: <base64-formated-password>
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: new-openshift-worker
  namespace: openshift-machine-api
spec:
  online: true
  bootMACAddress: <MAC-address>
  rootDeviceHints:
    deviceName: "/dev/sda"
  bmc:
    address: <bmc_address>
    credentialsName: openshift-worker-bmc-secret
  preprovisioningNetworkDataName:
      new-worker-network-config
~~~

All this information is included in this KCS article i have created https://access.redhat.com/solutions/6957587 until the documentation is fixed.

Regarding the networkData object im still not sure what is the difference and in what cases it must be used instead. So if you have any insight on this please share.

Thank you.

Comment 2 Steven Hardy 2022-05-24 14:04:05 UTC
Also note preprovisioningNetworkDataName is optional - in the default DHCP case no configuraiton is needed, which is not clear in the current docs where the BMH contains the (incorrect) networkConfig field

Comment 4 Adina Wolff 2022-05-30 08:24:47 UTC
Moving this back to 'assigned' since the PR hasn't been merged yet.

Comment 5 avbhatt 2022-05-30 10:07:31 UTC
Moving this back to ON_QA since the fix is implemented in the docs PR and it can't be merged without QE ack/approval/lgtm

Comment 6 avbhatt 2022-05-30 11:27:42 UTC
Moving this to POST after discussing it with @awolff

Comment 7 avbhatt 2022-05-31 11:24:03 UTC
Moving this to ON_QA based on the OpenShift Doc guidelines (https://github.com/openshift/openshift-docs/blob/main/contributing_to_docs/doc_guidelines.adoc#verification-of-your-content)

Comment 8 Adina Wolff 2022-05-31 12:39:08 UTC
Procedure tested successfully on 4.10


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