proposal to remove trigger activations when no rules are matched

[Rodric Rabbah <ro...@gmail.com>]

Today we create activation records for triggers regardless of a matching
rule. This can lead to many trigger activations that are not actually doing
anything useful. The system incurs the cost of creating the activation
record and no actions are run.

On the one hand, it's useful to see a trigger activation records when one
creates a trigger and just fires it to get an activation id. But the cost
for supporting this is too high in general. I am proposing only creating an
activation record for a trigger if there is a rule matched (and hence an
action is invoked).

This will reduce the load on the system in terms of useless events
(establishing an event source but not creating any actions to react to
them).

This will require an API change: when a trigger is fired (assuming it
exists, and the subject is authorized to fire it), today the controller
will return 200 OK and an activation id. I propose instead to change the
status code should to 202 Accepted if and only if the trigger has a
corresponding active rule, an 204 No Content otherwise.

I'd like to consider this as a first step as part of a larger item that can
be encompassed by https://github.com/apache/incubator-openwhisk/issues/512.

A subsequent step that I'd like to propose is to eliminate the separate
rule activation record. Instead, the controller should record the matched
rules in the trigger activation record (either as synthetic logs akin to
sequences or as annotations) along with the activation ids of all caused
invocations. Currently there is no visibility to the client in terms of the
activations ids that are caused by a rule, and this leads to a poor user
experience.

In turn, this will also reduce the activations load on the database from
the controller, and more importantly allow the client to have visibility
into event causality.

I welcome feedback on this topic and will consolidate feedback into the
issue cited above for implementation.

-r

Re: proposal to remove trigger activations when no rules are matched

[Carlos Santana <cs...@gmail.com>]

+1 to Rodric’s proposal

Making the controller do waist work and backend save data for useless is
not good.


James
what Steven proposed is a very simple way to test a trigger when you get
started.
Also what Rodric is proposing would allowed what you requested to have
event causality meaning we would record in action activation which trigger
activated the action.
On Thu, Nov 16, 2017 at 6:50 AM Stephen Fink <fi...@gmail.com> wrote:

> I’d propose we simply document a best practice that if you want to observe
> trigger firings, hook up the trigger to an echo action.
>
> SJF
>
> > On Nov 16, 2017, at 6:48 AM, James Thomas <jt...@gmail.com> wrote:
> >
> > On 14 November 2017 at 19:47, Rodric Rabbah <ro...@gmail.com> wrote:
> >> Today we create activation records for triggers regardless of a matching
> >> rule. This can lead to many trigger activations that are not actually
> doing
> >> anything useful. The system incurs the cost of creating the activation
> >> record and no actions are run.
> >
> > As a user, I do find it useful to see trigger activations, even when
> > I've not yet attached a rule. It helps me see I've set up the trigger
> > feed correctly, with the event parameters being logged.
> > It would be more difficult if I could only check the activations by
> > creating a "no-op" action to attach.
> >
> > What would happen with rules that are disabled?
> >
> > If this issue is happening for triggers, would future load from other
> > invocations (actions, rules) eventually encounter the same issue?
> >
> > I can understand trigger invocations will be a significant load on the
> > backend, as people leave old triggers connected to feeds. Removing
> > this does make the "developer experience" worse IMO. It'll be a
> > trade-off between this and performance unless there's a more scalable
> > way to manage the activation records.
> >
> >
> >> I'd like to consider this as a first step as part of a larger item that
> can
> >> be encompassed by
> https://github.com/apache/incubator-openwhisk/issues/512.
> >>
> >> A subsequent step that I'd like to propose is to eliminate the separate
> >> rule activation record. Instead, the controller should record the
> matched
> >> rules in the trigger activation record (either as synthetic logs akin to
> >> sequences or as annotations) along with the activation ids of all caused
> >> invocations. Currently there is no visibility to the client in terms of
> the
> >> activations ids that are caused by a rule, and this leads to a poor user
> >> experience.
> >
> > This sounds good.
> >
> > --
> > Regards,
> > James Thomas
>
>

Re: proposal to remove trigger activations when no rules are matched

[Stephen Fink <fi...@gmail.com>]

I’d propose we simply document a best practice that if you want to observe trigger firings, hook up the trigger to an echo action.

SJF

> On Nov 16, 2017, at 6:48 AM, James Thomas <jt...@gmail.com> wrote:
> 
> On 14 November 2017 at 19:47, Rodric Rabbah <ro...@gmail.com> wrote:
>> Today we create activation records for triggers regardless of a matching
>> rule. This can lead to many trigger activations that are not actually doing
>> anything useful. The system incurs the cost of creating the activation
>> record and no actions are run.
> 
> As a user, I do find it useful to see trigger activations, even when
> I've not yet attached a rule. It helps me see I've set up the trigger
> feed correctly, with the event parameters being logged.
> It would be more difficult if I could only check the activations by
> creating a "no-op" action to attach.
> 
> What would happen with rules that are disabled?
> 
> If this issue is happening for triggers, would future load from other
> invocations (actions, rules) eventually encounter the same issue?
> 
> I can understand trigger invocations will be a significant load on the
> backend, as people leave old triggers connected to feeds. Removing
> this does make the "developer experience" worse IMO. It'll be a
> trade-off between this and performance unless there's a more scalable
> way to manage the activation records.
> 
> 
>> I'd like to consider this as a first step as part of a larger item that can
>> be encompassed by https://github.com/apache/incubator-openwhisk/issues/512.
>> 
>> A subsequent step that I'd like to propose is to eliminate the separate
>> rule activation record. Instead, the controller should record the matched
>> rules in the trigger activation record (either as synthetic logs akin to
>> sequences or as annotations) along with the activation ids of all caused
>> invocations. Currently there is no visibility to the client in terms of the
>> activations ids that are caused by a rule, and this leads to a poor user
>> experience.
> 
> This sounds good.
> 
> -- 
> Regards,
> James Thomas

Re: proposal to remove trigger activations when no rules are matched

[James Thomas <jt...@gmail.com>]

On 14 November 2017 at 19:47, Rodric Rabbah <ro...@gmail.com> wrote:
> Today we create activation records for triggers regardless of a matching
> rule. This can lead to many trigger activations that are not actually doing
> anything useful. The system incurs the cost of creating the activation
> record and no actions are run.

As a user, I do find it useful to see trigger activations, even when
I've not yet attached a rule. It helps me see I've set up the trigger
feed correctly, with the event parameters being logged.
It would be more difficult if I could only check the activations by
creating a "no-op" action to attach.

What would happen with rules that are disabled?

If this issue is happening for triggers, would future load from other
invocations (actions, rules) eventually encounter the same issue?

I can understand trigger invocations will be a significant load on the
backend, as people leave old triggers connected to feeds. Removing
this does make the "developer experience" worse IMO. It'll be a
trade-off between this and performance unless there's a more scalable
way to manage the activation records.


> I'd like to consider this as a first step as part of a larger item that can
> be encompassed by https://github.com/apache/incubator-openwhisk/issues/512.
>
> A subsequent step that I'd like to propose is to eliminate the separate
> rule activation record. Instead, the controller should record the matched
> rules in the trigger activation record (either as synthetic logs akin to
> sequences or as annotations) along with the activation ids of all caused
> invocations. Currently there is no visibility to the client in terms of the
> activations ids that are caused by a rule, and this leads to a poor user
> experience.

This sounds good.

-- 
Regards,
James Thomas