Skip to content

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

Merged
merged 31 commits into from
Mar 18, 2022

Conversation

csviri
Copy link
Collaborator

@csviri csviri commented Mar 15, 2022

No description provided.

@csviri csviri marked this pull request as ready for review March 15, 2022 13:38
@csviri csviri self-assigned this Mar 15, 2022
@csviri csviri linked an issue Mar 15, 2022 that may be closed by this pull request
@csviri csviri changed the title (WIP) Separate interface for cleanup part of reconciler Separate interface for cleanup part of reconciler Mar 15, 2022
@csviri csviri requested a review from metacosm March 15, 2022 13:39
@metacosm
Copy link
Collaborator

See #922 (comment)

@csviri csviri force-pushed the separate-cleanup branch from ee0c9ed to 396b5a1 Compare March 16, 2022 09:37
@csviri csviri changed the title Separate interface for cleanup part of reconciler Separate interface for cleanup part of reconciler and Dependent Resources Mar 16, 2022
*/
@FunctionalInterface
public interface Cleaner<P extends HasMetadata> {
void cleanup(P primary, Context<P> context);
Copy link
Collaborator

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

Copy link
Collaborator Author

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?

Copy link
Collaborator

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…

Copy link
Collaborator Author

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);
Copy link
Collaborator

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).

Copy link
Contributor

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 ?

Copy link
Collaborator Author

@csviri csviri Mar 18, 2022

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.

Copy link
Collaborator Author

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.

@@ -58,40 +52,42 @@ public Controller(Reconciler<P> reconciler,

@Override
public DeleteControl cleanup(P resource, Context<P> context) {
dependents.cleanup(resource, context);
Copy link
Contributor

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);
Copy link
Contributor

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 ?

* @param <P> primary resource type
*/
@FunctionalInterface
public interface Cleaner<P extends HasMetadata> {
Copy link
Contributor

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.

csviri and others added 6 commits March 18, 2022 08:34
…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]>
@metacosm
Copy link
Collaborator

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 🤷🏼

@csviri csviri requested a review from metacosm March 18, 2022 15:35
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 64 Code Smells

40.0% 40.0% Coverage
0.3% 0.3% Duplication

Copy link
Collaborator

@metacosm metacosm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@metacosm metacosm merged commit 5a9bbe2 into next Mar 18, 2022
@metacosm metacosm deleted the separate-cleanup branch March 18, 2022 19:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Extract Cleanup Interface from Reconciler
3 participants