createOrReplace() of PVC etc.

[stefanbethke]

In the issues, a question has come up multiple times, and I did not see a good solution (see #2060, #2454, #3745, ...)

The problematic flow goes like this:

1. Construct a resource (either from YAML or using a Builder)
2. Add the resource to the cluster using createOrReplace()
3. Do more things, wait for the next loop, etc.
4. Construct the ressource again, identical to the one in 1.
5. Try to update the resource using createOrReplace().

At this point, the expectation is that the second createOrReplace() will succeed. However, for a number of resources (PVC, Secret, Service) it fails with a 422 error, as immutable fields are being updated. For example, in a PVC, you normally do not set the volume property, but this is assigned automatically by the cluster. The second createOrReplace() will try to set volume to nil, which fails.

It is not clear to me how to handle this situation properly, especially when the second time around the resource could have slightly different parameters. For example for a PVC, it is legal to change the size of the volume.

Many people were expecting createOrReplace() to act similarly to kubectl apply, which tracks which fields the creation request set, and uses PATCH to only update those fields, ignoring the existing ones.

It would be fantastic if the client had some knowledge of which fields can be updated, and only try to update those, or throw an exception if any of the immutable fields were trying to be modified.

Handling this in the application/operator is possible, but it's cumbersome.

Any suggestions?

[shawkins]

Linking to #3896 - I think the approach so far has been to make the replace logic for the resource as much as possible be tolerant to multiple replace calls with things like

kubernetes-client/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/dsl/internal/core/v1/ServiceOperationsImpl.java

Line 173 in 496b7ed

protected Service modifyItemForReplaceOrPatch(Supplier<Service> currentSupplier, Service item) {

- but as you're noting that hasn't been done for all objects and there are other side effects to PUTS that are not desirable.

[stefanbethke]

I'm not sure I follow. Is the client expected to handle this properly and automatically already, and I should open issues for cases where this is not (yet) the case, or should I be using a different API to update resources that already exist, like the body of the method in the code you linked to?

[shawkins]

Is the client expected to handle this properly and automatically already

Not really. As you can tell by the previous issues this has been an on-going problem.

and I should open issues for cases where this is not (yet) the case

You can, but my intention is to add proper apply support. Basic support for server side apply has been added to fabric8 6.0 #3334

or should I be using a different API to update resources that already exist, like the body of the method in the code you linked to?

Using edit or patch can be better in these circumstances than using replace or createOrReplace.