-
Notifications
You must be signed in to change notification settings - Fork 213
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
Informer based CustomResourceEventSource and caching #581
Conversation
executeBufferedEvents(uid); | ||
} | ||
eventBuffer.addEvent(event.getRelatedCustomResourceID(), event); | ||
monitor.processedEvent(event.getRelatedCustomResourceID(), event); |
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 know that it was like that even before but wonder if that's correct as in fact here the event is added to a buffer for late processing. In case of failure, the event may also be put back to the buffer so I guess, processedEvent
should be invoked only when the event has been delivered to the controller. Eventually we can also add metrics about how long it takes for an event from the generation to the delivery.
@metacosm am I missing something ?
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.
That is probably a good point. The event is not processed at this time. We should probably take a look on this in a separate PR.
Note that we plan to remove the event from the context:
#538
so not sure how this part will look like after this issue. We might still receive events, but the whole event handling should be simplified.
Bumps [jandex-maven-plugin](https://github.com/wildfly/jandex-maven-plugin) from 1.1.1 to 1.2.1. - [Release notes](https://github.com/wildfly/jandex-maven-plugin/releases) - [Commits](wildfly/jandex-maven-plugin@1.1.1...1.2.1) --- updated-dependencies: - dependency-name: org.jboss.jandex:jandex-maven-plugin dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [mockito-core](https://github.com/mockito/mockito) from 3.12.4 to 4.0.0. - [Release notes](https://github.com/mockito/mockito/releases) - [Commits](mockito/mockito@v3.12.4...v4.0.0) --- updated-dependencies: - dependency-name: org.mockito:mockito-core dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
@lburgazzoli @metacosm pls review this |
private ConfigurationService service; | ||
|
||
public AnnotationConfiguration(ResourceController<R> controller) { | ||
this.controller = controller; | ||
this.annotation = Optional.ofNullable(controller.getClass().getAnnotation(Controller.class)); | ||
this.annotation = controller.getClass().getAnnotation(Controller.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.
An exception should be thrown here if the annotation isn't present on the ResourceController.
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 if I get this. Did I change something on the behavior?
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, now if the annotation is not present then you'll get an NPE. It's fine to simplify all over as long as we fail early and tell the user that they need the annotation here, I think.
@@ -176,11 +163,14 @@ private boolean executeBufferedEvents(String customResourceUid) { | |||
newEventForResourceId, | |||
controllerUnderExecution, | |||
latestCustomResource.isPresent()); | |||
if (latestCustomResource.isEmpty()) { |
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.
What should be done in this case? Shouldn't we try to get the resource from the cluster?
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 if we assume that we receiving events reliably this is going to be ok eventually, would not complicate the code. I've put there a warning because in this case actually is a user error with some custom event source, so there is a sign of it.
Did not change the behavior now, this is same as was before just added logging.
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 would create a separate issues where we can discuss this situtation.
boolean newEventsExists = eventBuffer.newEventsExists(executionScope.getCustomResourceUid()); | ||
eventBuffer.putBackEvents(executionScope.getCustomResourceUid(), executionScope.getEvents()); | ||
boolean newEventsExists = eventBuffer | ||
.newEventsExists(CustomResourceID.fromResource(executionScope.getCustomResource())); |
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.
Why are we building the id from the CR here but then use getCustomResourceID
later?
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.
fixed.
eventBuffer.putBackEvents(executionScope.getCustomResourceUid(), executionScope.getEvents()); | ||
boolean newEventsExists = eventBuffer | ||
.newEventsExists(CustomResourceID.fromResource(executionScope.getCustomResource())); | ||
eventBuffer.putBackEvents(executionScope.getCustomResourceID(), executionScope.getEvents()); |
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'd make sense to use a local variable for executionScope.getCustomResourceID()
in this method
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.
fixed
|
||
/** @deprecated use {@link #addEvent(String, Event)} */ | ||
@Deprecated | ||
public void addEvent(Event event) { |
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.
Why isn't this not deprecated anymore?
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 did not see why it was actually before. But this is going away in the subsequent PR. (The whole even buffer concept)
@@ -80,13 +79,13 @@ public void eventFilteredByCustomPredicateAndGenerationAware() { | |||
cr.getMetadata().setGeneration(1L); | |||
cr.getStatus().setConfigMapStatus("1"); | |||
|
|||
eventSource.eventReceived(Watcher.Action.MODIFIED, cr); | |||
eventSource.eventReceived(ResourceAction.UPDATED, cr, null); |
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.
Shouldn't there be an old version of the CR here?
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.
fixed
@@ -44,35 +43,40 @@ public void skipsEventHandlingIfGenerationNotIncreased() { | |||
TestCustomResource customResource1 = TestUtils.testCustomResource(); | |||
customResource1.getMetadata().setFinalizers(List.of(FINALIZER)); | |||
|
|||
customResourceEventSource.eventReceived(Watcher.Action.MODIFIED, customResource1); | |||
customResourceEventSource.eventReceived(ResourceAction.UPDATED, customResource1, null); |
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.
Why is this null
here?
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.
fixed
@@ -222,7 +207,7 @@ public void successfulExecutionResetsTheRetry() { | |||
|
|||
@Test | |||
public void scheduleTimedEventIfInstructedByPostExecutionControl() { | |||
var testDelay = 10000l; | |||
var testDelay = 10000L; |
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.
Why a capital L
here and not in the next method?
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.
fixed
@@ -113,7 +114,7 @@ void updatesBothResourceAndStatusIfFinalizerSet() { | |||
when(customResourceFacade.replaceWithLock(testCustomResource)).thenReturn(testCustomResource); | |||
|
|||
eventDispatcher.handleExecution( | |||
executionScopeWithCREvent(Watcher.Action.MODIFIED, testCustomResource)); | |||
executionScopeWithCREvent(ResourceAction.UPDATED, testCustomResource)); |
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.
Why not use a static import here as well?
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.
fixed!
LGTM apart from the last annotation issue. Could you please rebase and squash before merging as well, making sure all the commit messages follow the conventional format? |
This is a major change and backbone of v2. We change also how the Resources are addressed both internally and from event source with CustomResourceID. Additional improvements also added.
a371629
to
76f4c00
Compare
feat: This is a major change and backbone of v2. We change also how the Resources are addressed both internally and from event source with CustomResourceID. Additional improvements also added. * chore: renaming vars named k8sClient to kubernetsClient * chore(deps): bump jandex-maven-plugin from 1.1.1 to 1.2.1 (#592) Bumps [jandex-maven-plugin](https://github.com/wildfly/jandex-maven-plugin) from 1.1.1 to 1.2.1. - [Release notes](https://github.com/wildfly/jandex-maven-plugin/releases) - [Commits](wildfly/jandex-maven-plugin@1.1.1...1.2.1) --- updated-dependencies: - dependency-name: org.jboss.jandex:jandex-maven-plugin dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * chore(deps-dev): bump mockito-core from 3.12.4 to 4.0.0 (#591) Bumps [mockito-core](https://github.com/mockito/mockito) from 3.12.4 to 4.0.0. - [Release notes](https://github.com/mockito/mockito/releases) - [Commits](mockito/mockito@v3.12.4...v4.0.0) --- updated-dependencies: - dependency-name: org.mockito:mockito-core dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * feature: Build PR on v2 * chore(ci): use Java 17 * chore(ci): use only Temurin distribution * chore: add generics to PostExecutionControl to reduce IDEs noise (#594) * chore: polish the junit5 extension (#593) * feat: Use informers as CustomResourceEventSource backbone and cache Co-authored-by: Ioannis Canellos <iocanel@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Chris Laprun <metacosm@gmail.com> Co-authored-by: Luca Burgazzoli <lburgazzoli@users.noreply.github.com>
No description provided.