TransportURL: rely on PatchInstance instead of manual Update #217
Conversation
|
I mixed things up. I need to rethink the reasoning to remove the extra update, but the issue is not as sever as I thought here. |
The transporturl controller did a separate client.Update after it initialized it status then continued the normal reconciliation. As it is explicitly updated the status subresource and no finalizer is added this probably works. However to allow easier reasoning about when the instance is updated this patch removes the explicit Update call and instead returns immediately to use the deferred PatchInstance call as the only place that persists the instance.
gibizer
force-pushed
the
remove-double-update
branch
from
73d2dca to
77fda22
Compare
gibizer
changed the title
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gibizer, stuggi 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:
Approvers can indicate their approval by writing |
|
recheck |
|
Build failed (check pipeline). Post https://review.rdoproject.org/zuul/buildset/79fa3a5dbde84ffe9ca0f745cc8c585c ✔️ openstack-k8s-operators-content-provider SUCCESS in 26m 33s |
|
recheck retry limit |
openshift-merge-bot
bot
merged commit ba41f87
into
openstack-k8s-operators:main
The transporturl controller did a separate client.Update after
it initialized it status then continued the normal reconciliation. As it
is explicitly updated the status subresource and no finalizer is added
this probably works. However to allow easier reasoning about when the
instance is updated this patch removes the explicit Update call and
instead returns immediately to use the deferred PatchInstance call
as the only place that persists the instance.