Don't set BaremetalHosts in the nodeset spec

[rabi]

Jira: https://issues.redhat.com/browse/OSPRH-12709

[rabi]

@abays Can you chime on what issues you see with this during update or we would need conversion webhook? I've disabled the check for field removal here for the crd-schema-checker to pass.

[rabi]

/hold

[softwarefactory-project-zuul]

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/openstack-k8s-operators/openstack-operator for 1258,b5755f51554ffa1b23c20f43d58d71024a0ab12e

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/63fdc7ab10ea4ecd81ad4901fc8c9024

✔️ openstack-k8s-operators-content-provider SUCCESS in 3h 12m 32s
✔️ podified-multinode-edpm-deployment-crc SUCCESS in 1h 21m 14s
❌ cifmw-crc-podified-edpm-baremetal FAILURE in 1h 38m 51s
✔️ adoption-standalone-to-crc-ceph-provider SUCCESS in 3h 00m 55s
✔️ openstack-operator-tempest-multinode SUCCESS in 1h 40m 48s

[rabi]

recheck

[abays]

@abays Can you chime on what issues you see with this during update or we would need conversion webhook? I've disabled the check for field removal here for the crd-schema-checker to pass.

I'm not entirely sure. But I think from an API perspective, if you're dropping fields in from the CRD, then existing CRs with the fields will just lose them the next time the CR is updated. That's the default behavior, at least, when you (as the user) add fields to a spec that don't actually exist in the underlying CRD. So my initial guess is that these fields will just disappear from the existing OpenStackDataPlaneNodeSet CRs and the API won't complain. But since the CRD schema checker wants to block removing fields without bumping the API version, it makes me suspect that I might be missing something. To be fair, I have never actually tried this.

[rabi]

To be fair, I have never actually tried this.

I tested this by updating the operators (uninstalling and installing) and there were no issues. I also realized that we test the same in the kuttl job[1] as well.

https://github.com/openshift/release/blob/master/ci-operator/step-registry/openstack-k8s-operators/kuttl/openstack-k8s-operators-kuttl-commands.sh#L144-L153

[rabi]

/unhold

[abays]

To be fair, I have never actually tried this.

I tested this by updating the operators (uninstalling and installing) and there were no issues. I also realized that we test the same in the kuttl job[1] as well.

https://github.com/openshift/release/blob/master/ci-operator/step-registry/openstack-k8s-operators/kuttl/openstack-k8s-operators-kuttl-commands.sh#L144-L153

Good point and good to know. 👍

[abays]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abays, rabi

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [abays,rabi]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rabi]

/test openstack-operator-build-deploy-kuttl