[GitHub] [flink-kubernetes-operator] gyfora commented on pull request #548: [FLINK-31407] Bump fabric8 version to 6.5.0

["gyfora (via GitHub)" <gi...@apache.org>]

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-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org