Always reset SetupReadyCondition to False

[rabi]

We use this condition to trigger deployments for a nodeset. Without this being reset to false, deployments would tigger before nodeset is reconciled for update/patch as the condition would be true.

[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://review.rdoproject.org/zuul/buildset/fc1d58b9de074058a5cf0c1e8f4124b7

✔️ openstack-k8s-operators-content-provider SUCCESS in 1h 32m 25s
✔️ podified-multinode-edpm-deployment-crc SUCCESS in 1h 07m 58s
❌ cifmw-crc-podified-edpm-baremetal FAILURE in 1h 15m 00s

[rabi]

recheck

[slagle]

I'd like to understand this a little better, and the scenario that's being solved.

deployments would tigger
before nodeset is reconciled for update/patch as the condition
would be true.

Only if the NodeSet is already SetupReady=True, and the deployment was already reconciling right? Specifically, are you trying to address the case where someone patches a NodeSet during an already reconciling Deployment?

It's likely an inconsistent pattern, but I don't see other conditions in other operators working the same as you're proposing here. Example, InputReady getting marked to False on every reconcile loop.

Forcing SetupReady=False on every reconcile seems unnecessary IMO, and may be inaccurate in many cases (we don't actually know that SetupReady is indeed False, granted we don't actually know that it's True either on every reconcile until we've checked).

[rabi]

Only if the NodeSet is already SetupReady=True, and the deployment was already reconciling right? Specifically, are you trying to address the case where someone patches a NodeSet during an already reconciling Deployment?

Nah, this is the scale-out case where a nodeset and deployment are both already reconciled. Then you patch the nodeset to add more nodes to the nodeset and create a (new) deployment. Because the nodset status is already SetupReady=True[1], the new deployment moves ahead and uses the old inventory and runs the aee jobs and the scale-out nodes are not deployed.

we don't actually know that SetupReady is indeed False, granted we don't actually know that it's True either on every reconcile until we've checked

During every reconcile we don't not know what is a specific status till reconciliation is gone through that step and updated the status. The assumption is that there won't be any reconcile if there is no spec change and if there is a spec change we don't know any of the statuses.

The other option is to evaluate SetupReady based on all other statuses that should be ready before that and in that case also we've to reset it back at the beginning of the reconciliation.

[1] https://github.com/openstack-k8s-operators/dataplane-operator/blob/main/controllers/openstackdataplanedeployment_controller.go#L148

[slagle]

Only if the NodeSet is already SetupReady=True, and the deployment was already reconciling right? Specifically, are you trying to address the case where someone patches a NodeSet during an already reconciling Deployment?

Nah, this is the scale-out case where a nodeset and deployment are both already reconciled. Then you patch the nodeset to add more nodes to the nodeset and create a (new) deployment. Because the nodset status is already SetupReady=True[1], the new deployment moves ahead and uses the old inventory and runs the aee jobs and the scale-out nodes are not deployed.

Ok, that makes sense. Sounds good to me.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bshephar, 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 [bshephar,rabi]

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

[rabi]

error: resource mapping not found for name: "openstack-galera" namespace: "openstack" from "STDIN": no matches for kind "OpenStackControlPlane" in version "core.openstack.org/v1beta1"
ensure CRDs are installed first

[rabi]

/test dataplane-operator-build-deploy-kuttl

[rabi]

/test dataplane-operator-build-deploy-kuttl