non-optimistic locking updateStatus

[shawkins]

updateStatus is implemented as a PUT to /status, which requires the resource to have a resourceVersion specified.

Is there a safe alternative to implementing this with a patch or edit instead?

For example it seems like updateStatus could produce a json patch string and call the new patch(PatchContext patchContext, String patch) method.

This is related to operator-framework/java-operator-sdk#409

Related to this and based upon comments in #2166 #2701 - is there a general issue with the current patch(T item) and edit calls in that they compute the diff based upon the current item compared to the changed item - if there is a resourceVersion specified on the item, shouldn't the diff be generated against that base version instead?

[shawkins]

Spawned #3067 to cover the related question on patching behavior.

[manusa]

#3078 (comment)

[shawkins]

Looking at the go client there is both a applyStatus and an updateStatus. Apply is a PATCH, and update is a PUT. I think the resolution here would be to add a similar applyStatus method to fabric8.

For consistency should fabric8 be using both the update and replace terms for a PUT call - that is should it be replaceStatus instead of updateStatus, or update(item) instead of replace(item)?

[shawkins]

With #3070 I'm proposing to add editStatus, patchStatus, and replaceStatus

[manusa]

I think that #3070 fixes this issue, status should be now modifiable in isolation of the rest of the resource, right?

[shawkins]

Yes, this fixed by #3070