repeatable sensors

[magaldima]

Is your feature request related to a problem? Please describe.
Initially, Argo Events was envisioned so that a sensor would only live for a single cycle. Once its dependencies were met and it executed it's triggers, it completed. However, this is annoying because now you have to keep creating new sensors for every cycle.

Describe the solution you'd like
The ability to create a sensor that lives past a single cycle. This can be a signal that fires every 30min or every business day or every business day after an S3 object arrives between 7am and 9am. We can create this sensor once and forget about it. It should re-instantiate or reset itself so that you don't have to create an entirely new one again that does the same thing.

There are a couple important things to consider for this:

• We don't want to over-write sensor history, we MUST keep track of what happened and never delete data.
• We still want visibility into an entire history chain of multiple cycles of a sensor (how many times it triggered in the past week)

Describe alternatives you've considered

• First alternative is that we don't support cyclical or repeatable sensors.
• Second alternative is for some other super process to figure out the total # of completions for a sensor and pass that in the sensor spec.
• Remove the concept of dependency and opt for a FaaS approach. This means that a sensor would then be restricted to at MAX one signal. With this approach, we can get repeatability easily, but we still need a way to store past events which Events as CRD #35 could be an easy solution or explore diff options through event log storage #4 .

[edlee2121]

How would repeatable/persistent sensors waiting for multiple events work?
A couple fo possibilities:

• Events must occur within a specified time interval.
• Events must have a matching field/condition.
  • This mean that there may be some events waiting for matching events.
• Some combination of the two where unmatched events expire after a specified time interval.

One way to view events would be conditions that trigger based on a history/log of events.

[magaldima]

@edlee2121 thanks for the perspective!

I think there may be a lot of value in de-coupling the event sources from a persistent event log in achieving the above. Splitting apart the Sensor CRD into smaller components may be a possible solution forward.

The smaller components could become:

• Sensors become a smaller CRD. It describes a source of events which are written to the Log.
• Events are conditions that trigger based on a additions to the Log.
• Log represents the history/log of all past events.
• Triggers define an Event condition and how to execute an action.

Users, then could separately create Sensors (event source) and Triggers (condition + action).

[bakayolo]

Definitely waiting for this great feature.
Do you know why we have the possibility to schedule a cron calendar signal if the sensor cannot be repeated more than once?

[VaibhavPage]

Addressed in #92