Existing Baremetal Provisioning CR ignored

[karmab]

Version

$ openshift-install version
openshift-baremetal-install 4.4.0-0.nightly-2020-01-24-141203
built from commit 96d416ee36d8660c3f2cb33863587455278f4ed2
release image registry.svc.ci.openshift.org/ocp/release@sha256:e4c521b17c773c4c0b1bd5816dc5f1660df16da8a28d68dc08394b879e8c6d91

Platform:

What happened?

when deploying on baremetal, metal3 pod doesnt properly start since the switch to consuming provisioning object instead of configmap.
Despite precreating the following CR by moving it into dedicated openshift directory, it's ignored and instead a default one is used, where provisioning nic is set to ens3 (which doesnt match my env where i'm using eno1 instead)

apiVersion: metal3.io/v1alpha1
kind: Provisioning
metadata:
  name: provisioning-configuration
  namespace: openshift-machine-api
spec:
  provisioningInterface: eno1
  provisioningIP: 172.22.0.3
  provisioningNetworkCIDR: 172.22.0.0/24
  provisioningDHCPExternal: False
  provisioningDHCPRange: 172.22.0.10,172.22.0.100

What you expected to happen?

Install to properly finish

How to reproduce it (as minimally and precisely as possible)?

Deploy latest openshift on baremetal, creating a custom provisioning object

[hardys]

We discussed this and I think the reason is you are manually creating the new CR, instead you should add the related configuration to your install-config ref #2958

I think this is happening because the default is ens3 (will be removed in #2976) so the installer generated CR is overwriting your manually generated one - the CR should only be created by the installer.

[hardys]

/retitle Existing Baremetal Provisioning CR ignored

[hardys]

/label platform/baremetal

[hardys]

I think this is working as designed, but perhaps we should add validation so the installer either skips writing the CR if it already exists, or maybe it would be better to fail since the expectation is that only the installer ever writes this CR? @imain @sadasu what are your thoughts?

[hardys]

One thing to consider is if we allow creating the CR outside the installer, it's possible to bypass the validation applied by the installer, which we probably don't want?

[stbenjam]

I think we always want the CR created by the installer so the values match up to platform config. The user also already has a direct influence through the installer what values get set in the CR, so I’m struggling to come up with a reason why you’d want to do it separately.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close