-
Notifications
You must be signed in to change notification settings - Fork 220
feat: decouple configuration of rate limiting and retry from controller #1317
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
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.
Not sure this is needed, since the getRetry
is called only once as far I remember.
Maybe if there are more controllers it spares some memory. But does not hurt.
LGTM
...ework-core/src/main/java/io/javaoperatorsdk/operator/api/config/ControllerConfiguration.java
Outdated
Show resolved
Hide resolved
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 have mixed feelings about this concept (well that includes positive ones :) ) , for now we had every configuration in @ControllerConfiguration
configutation, here some of the configuration would be not part of it but a separate annotation. It makes sense if users want to configure own implementation of these concepts (retry, rate limit). However the default implementations should cover most of the cases. The extensibility is mostly there for sake of generality.
I'm not opposing, I see what problem this solves, just pointing out that separate annotations, are subject of developers annoyance, since you have to learn this feature from the docs, not directly visible from the code.
Therefore we have to document this very carefully both in docs and javadoc
...-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/RetryConfiguration.java
Show resolved
Hide resolved
…va-operator-sdk into clean-configuration
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.
Made comments, mostly about naming.
.../src/main/java/io/javaoperatorsdk/operator/processing/event/rate/LimitingRateOverPeriod.java
Outdated
Show resolved
Hide resolved
/** | ||
* Optional list of {@link Dependent} configurations which associate a resource type to a | ||
* {@link io.javaoperatorsdk.operator.api.reconciler.dependent.DependentResource} implementation | ||
* | ||
* @return the list of {@link Dependent} configurations | ||
*/ | ||
Dependent[] dependents() default {}; | ||
|
||
Class<? extends Retry> retry() default GenericRetry.class; |
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 have some javadoc here? link how to configur it.
...e/src/main/java/io/javaoperatorsdk/operator/api/config/ControllerConfigurationOverrider.java
Show resolved
Hide resolved
...-core/src/main/java/io/javaoperatorsdk/operator/processing/event/rate/PeriodRateLimiter.java
Outdated
Show resolved
Hide resolved
this.limitForPeriod = configuration.maxReconciliations(); | ||
} | ||
|
||
public boolean isActivated() { |
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.
Don;t think this needs to be exposed, thus should not be public.
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.
It's used in a test in a different package so no choice… :(
...ework-core/src/main/java/io/javaoperatorsdk/operator/processing/retry/RetryingGradually.java
Outdated
Show resolved
Hide resolved
Addressed comments. |
Kudos, SonarCloud Quality Gate passed! |
…er (#1317) Co-authored-by: csviri <[email protected]>
…er (#1317) Co-authored-by: csviri <[email protected]>
…er (#1317) Co-authored-by: csviri <[email protected]>
…er (#1317) Co-authored-by: csviri <[email protected]>
No description provided.