Allow to "put back" events with TimerEventSource

[csviri]

When we trigger controller with some events, but executing on operation on a dependent resource would take longer time. We can schedule a controller execution with TimerEventSource - a one time event. To don't miss any information we want to give possibility to receive the actual events (or a subset of it - as user specifies) inside a one time event.

To undertstand it, the implementation would mean to extend (overload) TimerEventSource method:

https://github.com/java-operator-sdk/java-operator-sdk/blob/e1bc15691293302d0b897edeab2d91f857849a9a/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/internal/TimerEventSource.java#L32

with a version where we specify List of events we are going to put back.

[adam-sandor]

I don't understand the use-case here. Why is it a problem if an operation on a dependent resource takes time? Do you mean creating a DB in createOrUpdateResource taking too much time?

[csviri]

The idea is ( wha twe discussed this before I think in an Operator SDK comparison meeting) that we use one time events in case, when in a controller we have a particular step - yes, like a DB creation - which takes time and we wan't to "wait" until that happens and then go for the next steps further. Thus, this case we want to periodically execute the controller to check if the DB is ready yet or not, so to make sure that the controller executes in a reasonable time we set a OneTime event (again and again the DB is up). - This is what we arelady had.

The change here is that we also make it possible to provide the event that initially tiggered the execution. This will make sure to not loose this information (if sombody is making decision based on events).

Also makes it easier to migrate from OperatorSDK where putting back a even to reconcile again is a standard pattern. Its not the same, we don't have the exact API (probably even we don't want to), but definitelly possible to have a similar behavior in a relatively simple way.

[metacosm]

Can you explain using an example how this changes things? What does it provide that we couldn't previously do? Detailing the before and after cases would help understanding the use case…

[csviri]

Can you explain using an example how this changes things? What does it provide that we couldn't previously do? Detailing the before and after cases would help understanding the use case…

Sure (2 use cases):

Example / use case 1:

Let's assume that we use events in the controller to cordinate the workflow. (yes I advice agains this but might needed some cases)

For example in a controller we want to create an RDS database on AWS. And also deploy a service which uses that database after. (Note that we know the DB url after its been provisioned). So in a controller we initiate the DB create (AWS RDS Api call), we want to poll this DB creation. So we issue a OnceTimerEvent, but for now we was not able to tell to one time event more specific info, so we add there a DB Creation Initiated event as argument to the OnceTimerEvent. So in 1 minute we receive this OnceTimerEvent where we see that this has in an Event embedded which says we are executing the controller because there was a DB creation initiated before. So in the controller we check if the DB is ready (again AWS API call). If ready we can proceed creating the Service, if not we reschedule the event again.

When the DB is ready, we can start the same with the service, where we start a deployment, we schedule a OnceTimerEvent with a differnet content, and if we receive this one we won't check the DB, since we know that this contains an event related to service creation not the DB creation. And do the same "polling" also for the service.

(Now I'm thinking if having these info in one time event, not necessary even needs to imple Event interface - we can discuss what would be the best for that)

Example / use case 2: We have a operator in operator SDK, we want to migrate it to JOSDK, so to able to copy the actual behavior and not redesign the whole approach, we can map to Operator SDK "put back event" behavior to JOSDK behavior using OnceTimerEvent sources, and do the "put back" using those.

[adam-sandor]

Thanks for the detailed explanation. We discussed at some point to have examples for changes like this, can you create one? Maybe modify the MySQL sample to utilize this behavior? I think this is important to properly assess whether this will be useful for users (and to make sure people have a sample to look at on how/why to use it).

[metacosm]

OK, I think I understand the use case a little better now. Thank you.

[jmrodri]

Closing, stale.