gyfora commented on PR #548:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/548#issuecomment-1476388021
> I've just had a deeper look at the test issues and here are my findings:
>
> * The originally used `createOrReplace` has the following semantics
>
> * Create the resource with `POST` operation
> * If response is HTTP_CONFLICT (409) then replace the resource with
`PUT` operation (replace operation is effectively a forced update with retries)
> * The `createOrReplace` doc says the following:
> ```
> /**
> * Creates a provided resource in a Kubernetes Cluster. If creation
> * fails with a HTTP_CONFLICT, it tries to replace resource.
> *
> * @return created item returned in kubernetes api response
> *
> * @deprecated please user {@link
ServerSideApplicable#serverSideApply()} or attempt a create and edit/patch
operation.
> */
> @Deprecated
> T createOrReplace();
> ```
> * The doc is cloudy what `serverSideApply` really does so had an in-depth
look of the source code.
> * In case of custom resource the code is unconditionally patch the
resource with `PATCH` operation
>
> My general conclusion is that `createOrReplace` and `serverSideApply` are
having totally different semantics if we consider the source code. My proposal
is the following:
>
> * Use `create` when new resource is needed
> * Use `update` when existing resource need to be upgraded (since `replace`
is deprecated too)
> * If it's super hard to decide whether create or update is needed then one
can re-implement to original `createOrReplace` functionality but I discourage
to do it
I agree with @gaborgsomogyi 's assessment. If we need we can keep the
serverSideApply in some tests but we should not use it in the core logic.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
