-
Notifications
You must be signed in to change notification settings - Fork 218
feat: cache update on update control #2789
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 5 commits
41eb66f
80495e1
5d662b8
2d6a2a1
935637c
08e1b34
c1775a9
bc2cf5b
0d49575
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -457,14 +457,35 @@ default boolean previousAnnotationForDependentResourcesEventFiltering() { | |
* logic, and you want to further minimize the amount of work done / updates issued by the | ||
* operator. | ||
* | ||
* @return if resource version should be parsed (as integer) | ||
* @since 4.5.0 | ||
* @return if resource version should be parsed (as integer) | ||
* @return if resourceVersion should be parsed (as integer) | ||
*/ | ||
default boolean parseResourceVersionsForEventFilteringAndCaching() { | ||
return false; | ||
} | ||
|
||
/** | ||
* If you update the primary resource from the reconciler with or without {@link | ||
* io.javaoperatorsdk.operator.api.reconciler.UpdateControl} it is not guaranteed that for the | ||
* next reconciliation will receive the most up-to-date resource. This is a consequence of | ||
* Informers design in the Operator pattern. | ||
* | ||
* <p>The framework can be smart about it and make such guarantees, but this can be done | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This whole paragraph is less explicit and clear that what it could be, imo. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Will take a look thx. |
||
* absolutely reliably only if it bends some rules of the Kubernetes API contract. Thus, if we | ||
* parse the resourceVersion of a primary resource as an integer and compare it with the version | ||
* of the resource in the cache. Note that this is a gray area, since with default setup Etcd | ||
* guarantees such monotonically increasing resource versions. But since it is still bending the | ||
* rules by default, this feature is turned off, and work only if {@link | ||
* #parseResourceVersionsForEventFilteringAndCaching} is also set to true. | ||
* | ||
* <p>See also {@link io.javaoperatorsdk.operator.api.reconciler.PrimaryUpdateAndCacheUtils} | ||
* | ||
* @return if the framework should cache the updated resource for next reconciliation | ||
*/ | ||
default boolean cacheUpdatedResourcesViaUpdateControl() { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does it make sense to have a different option for this? More precisely, wouldn't it make sense to activate automatic caching whenever parsing of the resource version is activated? I mean the name of the parse method already implies that it is used for caching. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not exactly, parsing resource version was done for now only in dependent resources. I think this should be an opt-in feature since it does not strictly follows K8S API contract, so user should be aware. I would not turn it on by default for the low level API. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also if there are some issues user can still turn it off. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that adding options for corner cases makes things a lot more complex to understand, especially when the setting only applies when some other setting is enabled. To me, all these options should really be hidden under a single one where everything that can be done by assuming the resource versions grow monotonically should be done automatically when parsing is activated. Also, if there are potential issues, then we probably shouldn't have the features to start with. Either we can implement it correctly or we shouldn't provide the feature. That's something I actually dislike with the SSA support: it's not working in all cases and makes things more complex to the point that people might not want to use it or actually revert to using optimistic-looking based updates. This isn't great. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, the method name isn't correct as the setting impacts more than updates via There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I don't see what SSA has to do with optimistic locking. OL can be turned on all update / patch types. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It's not about potential issues, I don't see any, but it is good to have a failsafe. Note that this what we have is again bending a bit the Kuberentes API contract. It is safe with ETCD at the backed, might be different for a non etc etc. For what we provide the alternative explicit cache. |
||
return false; | ||
} | ||
|
||
/** | ||
* {@link io.javaoperatorsdk.operator.api.reconciler.UpdateControl} patch resource or status can | ||
* either use simple patches or SSA. Setting this to {@code true}, controllers will use SSA for | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't really make sense. What's the point of referring to UpdateControl if that can happen whether we use it or not?