--- Additional comment from Antonio Murdaca on 2020-04-30 01:45:10 UTC --- Turns out the CRD validation in MCO is wiping out unknown fields (unknown as "not specified in the CRD). That can cause all sort of issues if you specify something which depends on whatever was about to be done with something that went away after the MachineConfig gets created. There's a PR already for the 4.4 branch. I'll work on that asap. --- Additional comment from Antonio Murdaca on 2020-04-30 01:48:00 UTC --- WIP PR here (I'll adjust BZs tomorrow) https://github.com/openshift/machine-config-operator/pull/1698
Test plan, from Colin in [1]: > Anyone who wants to test this, it should be sufficient to do oc create on this: https://github.com/openshift/release/blob/23b3ddb6b32e8157e9b882172264b8d1b008070c/clusters/build-clusters/01_cluster/machine_config/m5d4x_machineconfig.yaml > > Then, notice the storage/disks field is dropped: > > $ oc describe machineconfig/m5d4x > ... > storage: {} > After this PR merges you should see the storage section from the submitted object. [1]: https://github.com/openshift/machine-config-operator/pull/1698#issuecomment-621572770
Verified in 4.4.0-0.nightly-2020-04-30-051505 Create the machineconfig https://github.com/openshift/release/blob/23b3ddb6b32e8157e9b882172264b8d1b008070c/clusters/build-clusters/01_cluster/machine_config/m5d4x_machineconfig.yaml >, the storage field is not dropped oc describe machineconfig m5d4x Name: m5d4x Namespace: Labels: machineconfiguration.openshift.io/role=worker-m5d4x Annotations: <none> API Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Metadata: Creation Timestamp: 2020-04-30T06:34:32Z Generation: 1 Resource Version: 23139 Self Link: /apis/machineconfiguration.openshift.io/v1/machineconfigs/m5d4x UID: 878865b9-3117-4328-8564-af43ca5ef337 Spec: Config: Ignition: Version: 2.2.0 Storage: Disks: Device: /dev/nvme1n1 Partitions: Label: containerraid1 Number: 0 Size: 0 Start: 0 Wipe Table: true Device: /dev/nvme2n1 Partitions: Label: containerraid2 Number: 0 Size: 0 Start: 0 Wipe Table: true Filesystems: Mount: Device: /dev/md/containerraid Format: xfs Label: containers Raid: Devices: /dev/disk/by-partlabel/containerraid1 /dev/disk/by-partlabel/containerraid2 Level: stripe Name: containerraid Systemd: Units: Contents: [Mount] What=/dev/md/containerraid Where=/var/lib/containers Type=xfs [Install] WantedBy=local-fs.target Name: var-lib-containers.mount
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