-
Notifications
You must be signed in to change notification settings - Fork 220
Separate interface for cleanup part of reconciler and Dependent Resources #1035
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
Conversation
See #922 (comment) |
ee0c9ed
to
396b5a1
Compare
...javaoperatorsdk/operator/processing/dependent/kubernetes/CruKubernetesDependentResource.java
Outdated
Show resolved
Hide resolved
...javaoperatorsdk/operator/processing/dependent/kubernetes/CruKubernetesDependentResource.java
Outdated
Show resolved
Hide resolved
...k-core/src/main/java/io/javaoperatorsdk/operator/api/reconciler/ControllerConfiguration.java
Outdated
Show resolved
Hide resolved
*/ | ||
@FunctionalInterface | ||
public interface Cleaner<P extends HasMetadata> { | ||
void cleanup(P primary, Context<P> context); |
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.
Maybe this should also return a DeleteControl
object, but then this doesn't work very well with the method being named cleanup
instead of delete
…
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.
How that would work with more Dependent Resources returning different Delete Controls?
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.
Good point. Ultimately, though, I think it will make sense for dependent resources to return more information so that the main reconciler can make decisions based on the returned status…
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.
Yes, for now only the state is available, at that time. Although we changed the reconcile()
to return ReconcileResult
this result is not available. Not sure if I would push this further ATM, but would be make those results also available in the future.
|
||
@Override | ||
public DeleteControl execute() { | ||
dependents.cleanup(resource, context); |
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.
So the idea is that dependents will get cleaned even if the main reconciler doesn't implement Cleaner
? That does seem a little weird since the whole point of implementing Cleaner
on Reconciler
is to clean dependent resources (since the primary one is already dealt with).
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.
I agree, dependent cleanup should be called only if the reconciler implement Cleaner
. Maybe a warning or a controller configuration exception should be raised if dependents and reconciler do not align ?
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.
I think this is kinda a side effect that we don't have this in layers. In case of a special Reconciler this could be done very transparent way. Will create one prototype in the future.
If you take a look from the other point of view, even the reconcile
method could be empty when using managed dependent resources, what is already weird. So if we have managed dependent resources where does implement cleaner, the custom resources must have a finalizer otherwise it does not work. And also cleanup
needs to be called.
I agree that this is little weird, but the other alternative is to just log a warning, and don't do finalizer and cleanup call, is very error prone in sense that could lead easily to operator implementation that is not correct.
So personally I would go this way, so rather have under the hood something happening that is correct but maybe not intuitive (however nicely documented), and users could then rather check / learn why is this happening. It might cause less headaches then having not cleaned up resources, because Cleaner
is not implement on reconciler.
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.
But I don't have actually that strong opinion, just lean to this. Let me know what do you think about this reasoning, we can change in case.
...avaoperatorsdk/operator/processing/dependent/kubernetes/CrudKubernetesDependentResource.java
Outdated
Show resolved
Hide resolved
...java/io/javaoperatorsdk/operator/processing/event/source/controller/ResourceEventFilter.java
Outdated
Show resolved
Hide resolved
...java/io/javaoperatorsdk/operator/processing/event/source/controller/ResourceEventFilter.java
Outdated
Show resolved
Hide resolved
...java/io/javaoperatorsdk/operator/processing/event/source/controller/ResourceEventFilter.java
Outdated
Show resolved
Hide resolved
…operator-sdk into separate-cleanup
@@ -58,40 +52,42 @@ public Controller(Reconciler<P> reconciler, | |||
|
|||
@Override | |||
public DeleteControl cleanup(P resource, Context<P> context) { | |||
dependents.cleanup(resource, context); |
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.
I noticed recently it was excluded but IMHO having a metric for the total time should exists.
If needed, we can add a per dependent scoped metric.
|
||
@Override | ||
public DeleteControl execute() { | ||
dependents.cleanup(resource, context); |
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.
I agree, dependent cleanup should be called only if the reconciler implement Cleaner
. Maybe a warning or a controller configuration exception should be raised if dependents and reconciler do not align ?
...ore/src/main/java/io/javaoperatorsdk/operator/processing/event/ReconciliationDispatcher.java
Outdated
Show resolved
Hide resolved
...ore/src/main/java/io/javaoperatorsdk/operator/processing/event/ReconciliationDispatcher.java
Outdated
Show resolved
Hide resolved
...samples/common/src/main/java/io/javaoperatorsdk/operator/sample/CustomServiceReconciler.java
Outdated
Show resolved
Hide resolved
* @param <P> primary resource type | ||
*/ | ||
@FunctionalInterface | ||
public interface Cleaner<P extends HasMetadata> { |
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.
+1 it will also help disambiguate import resolution due to the same class name.
…operator-sdk into separate-cleanup
…tor/processing/dependent/kubernetes/CruKubernetesDependentResource.java Co-authored-by: Chris Laprun <[email protected]>
…tor/processing/event/source/controller/ResourceEventFilter.java Co-authored-by: Chris Laprun <[email protected]>
…tor/processing/event/ReconciliationDispatcher.java Co-authored-by: Sébastien CROCQUESEL <[email protected]>
…operator-sdk into separate-cleanup
More generally speaking, I would have preferred we moved the classes in a different PR so that it's easier to follow and merge other waiting PRs. That said, I've done this before as well so 🤷🏼 |
Kudos, SonarCloud Quality Gate passed! |
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.
LGTM
No description provided.