Mailing-List: contact dev-help@openwhisk.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openwhisk.apache.org
MIME-Version: 1.0
References: <CAAC1_d5KduPSFqqa7dMhbY5DS3u=N42+kjZw3EXAo_mZfscbpw@mail.gmail.com>
 <CAH3ObvohrDtjxis+SCXUjtems35wNdSLGRNPapaANkwk3skG=w@mail.gmail.com> <19124675-062A-48C2-AAC2-87A26B9D0FAE@gmail.com>
In-Reply-To: <19124675-062A-48C2-AAC2-87A26B9D0FAE@gmail.com>
From: Carlos Santana <csantana23@gmail.com>
Date: Fri, 17 Nov 2017 09:52:32 +0000
Message-ID: <CAHYtTqmKtozhhF=j=Brg3RrGTBx9R8YDdMrY84wD3hKxksvm2Q@mail.gmail.com>
Subject: Re: proposal to remove trigger activations when no rules are matched
To: dev@openwhisk.apache.org
Content-Type: multipart/alternative; boundary="001a1142680cbad080055e2ab273"
archived-at: Fri, 17 Nov 2017 09:52:49 -0000

--001a1142680cbad080055e2ab273
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1 to Rodric=E2=80=99s 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 <fink.stephen@gmail.com> wrote=
:

> I=E2=80=99d propose we simply document a best practice that if you want t=
o observe
> trigger firings, hook up the trigger to an echo action.
>
> SJF
>
> > On Nov 16, 2017, at 6:48 AM, James Thomas <jthomas.uk@gmail.com> wrote:
> >
> > On 14 November 2017 at 19:47, Rodric Rabbah <rodric@gmail.com> wrote:
> >> Today we create activation records for triggers regardless of a matchi=
ng
> >> 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 tha=
t
> 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 separat=
e
> >> 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 caus=
ed
> >> invocations. Currently there is no visibility to the client in terms o=
f
> the
> >> activations ids that are caused by a rule, and this leads to a poor us=
er
> >> experience.
> >
> > This sounds good.
> >
> > --
> > Regards,
> > James Thomas
>
>

--001a1142680cbad080055e2ab273--