Allowing conflict resolution strategy in UpdateControl

[wylswz]

Conflict may happen during status update, is it possible to allow specifying resolution strategies such like

• retry times
• retry wait intervals
• resolution strategies, for example like

// resourceVersion handled by framework
(oldVersion, newVersion) -> {
  oldVersion.setSpec(newVersion.getSpec());
  return oldVersion;
}

Currently I'm doing this by my self and return a UpdateControl.noUpdate() in reconcile() method, however, if my status implements ObservedGenerationAwareStatus, there's an implicit update...

Same thing applies to ObservedGenerationAwareStatus as well. Currently I have to override update() method and invoke my own updater. It would be really nice if there's a declarative way to do this.

[csviri]

Hi @wylswz , in v5 the status will be handled with SSA, which should avoid conflicts. For now you can do it as you said just on your own in reconciliation.

if my status implements ConfigFileDistributionStatus, there's an implicit update...

I have no clue what is ConfigFileDistributionStatus. It implements observed generation handling, that is what you referring to?

Same thing applies to KubernetesDependentResource as well. Currently I have to override update() method and invoke my own updater. It would be really nice if there's a declarative way to do this.

Dependent resources already use SSA, it should not happen, what version of framework are you using?

[csviri]

The retry is currently generic but configurable, that is the intended way to handle optimistic locking issues atm.

[wylswz]

Sorry, that was my CRD's name, yes, observed generation handling is exactly what I was meaning.

I'll take a look at SSA, thanks for your reply!

[wylswz]

I'm using 4.8.2. I'll remove the explicit retry in DependentResources and see if it reproduces today.

[wylswz]

didn't reproduce in DependentResources, will close the discussion, thanks