openwhisk alarms not allowed on local environment

[Urs_Boller]

I tried to add openwhisk alarms to my app using /whisk.system/alarms https://github.com/AdobeDocs/adobeio-runtime/blob/33d0979a45b9e35e8addaad7e97dfb00f8ea5e12/reference... and added a new trigger to my manifest.yml file as following:

    triggers:
      myIntervalTest:
        feed: /whisk.system/alarms/interval
        inputs: 
          minutes: '5'
          start-date: "2020-08-30T19:30:00.000Z"
          stop-date: "2020-08-30T21:30:00.000Z"
          payload: "{}"

 and running local dev server with "aio app run --local" I get the following error message:

OpenWhiskError: POST http://localhost:3233/api/v1/namespaces/whisk.system/actions/alarms/interval?blocking=true Returned HTTP 403 (Forbidden) --> "The supplied authentication is not authorized to access 'whisk.system/alarms'."

Question 1: what do I need to change to get proper authentication?

on the other hand, it runs leaving out the "--local" parameter with the following message:

Local Dev Serverinterval:0ebaeb2b80054388baeb2b800523887b

so it looks as the trigger has successfully been placed on whisk with the desired interval.

but as soon as the trigger reaches the interval, the following error message appears in console:

 stdout: alarm: Error invoking whisk action: 204 undefined

I double checked any spellings and everything looks fine, here are just the main entries from manifest.yml

packages:
  __APP_PACKAGE__:
    license: Apache-2.0
    actions:
      testAlarmsPackage:
        function: actions\testAlarmsPackage\index.js
        web: 'yes'
        runtime: 'nodejs:12'
        inputs:
          LOG_LEVEL: debug
        annotations:
          require-adobe-auth: true
          final: true
    triggers:
      myIntervalTest:
        feed: /whisk.system/alarms/interval
        inputs: 
          {see above}
    rules:
      runTestAlarms2:
        trigger: myIntervalTest
        action: testAlarmsPackage

I tryed to change the names for trigger and action in the rules set to confirm it is no spelling mistake. spelling mistakes break the build and output following messages:

Error: Action/Trigger provided in the rule not found in manifest file

Question 2: Any ideas what to change so that the alarm can trigger the right action?

[duypnguyen · Accepted solution]

Hi @Urs_Boller, here are answers relevant to your questions.

Answer 1: It is not possible to deploy an alarmed trigger in `--local` mode, because the alarms provider and packages are not deployed in your local openwhisk. You have to deploy it on I/O Runtime (without `--local`).

Answer 2: I tried the same setup as yours and it seems to work for me. The only difference is, I set the `require-adobe-auth` flag to false and removed `web: yes`, because the alarm is not able to provider a token as a web request. That way the action is still secure and can only be triggered by the alarm, not an external entity.

packages:
  __APP_PACKAGE__:
    license: Apache-2.0
    actions:
      generic:
        function: actions/generic/index.js
        runtime: 'nodejs:12'
        inputs:
          LOG_LEVEL: debug
        annotations:
          require-adobe-auth: false
          final: true
    triggers:
      testInterval:
        feed: /whisk.system/alarms/interval
        inputs: 
          minutes: 1
    rules:
      testIntervalRule:
        trigger: testInterval
        action: generic

[Urs_Boller]

Hi @duypnguyen thanks very much - worked perfect and rule is triggered/running as expected!! that is really awesome

just two more questions:

1. Is it correct that without the attribut "web:yes" the action can't be accessed from anywhere, only used by triggers and events? so there is no way from outside to trigger the action and receive the results?
2. Do you know of a way to locally turn off the alarm package (when running "aio app run"), but adding it as soon as I run "aio app deploy"? do I need to manually setup a workflow that sets my manifest.yml based on where I want to deploy?

Thanks a lot for your support!

[duypnguyen]

Hi @Urs_Boller.

Yes that's right, without `web: yes` your action can only be invoked by a trigger or directly by you in command line (aio runtime action invoke). Not possible to trigger from outside. IMO it makes sense from a security perspective, because you are assured that there is only one entry point per entity.

From the other thread I understand that you want to expose the same action functionalities to the UI as well. I would propose to create a (npm) library for the common methods of the shared functionalities. Because the authentication is not the same for headless (alarm-based) app and SPA (UI-based), you would need 2 apps in that case. So the action in the headless app doesn't have web exposure and is only triggered by alarm. On the other hand, the action in the SPA has web exposure and require-adobe-auth turned on so that it's only accessible by authorized users.

I'm not aware of a way to disregard the alarms set up in development mode. But that could be a good enhancement for the Firefly tooling. Do you mind creating a new issue in our CLI app plugin for this enhancement request? https://github.com/adobe/aio-cli-plugin-app

[Urs_Boller]

@duypnguyen I don't want to access the same action from both triggers (interval) as well as UI - it was just my first idea during testing. What we do now is having a backend action (headless action) which is triggered by whisk/alarms and the UI just displays the result. If we want, we can pass settings to the headless action by using another action that sets some keys using aio-lib-state

[Urs_Boller]

@duypnguyen and thanks for confirmation about security concerns, it looks as it is exactly what we are looking for (running an action in background doing all the stuff)

[Urs_Boller]

@duypnguyen just realised that my "interval" action does not stop (ignoring the param "stop-date". do you know what the key is to stop the alarm?

[duypnguyen]

Ah ok, that's good to know. Great idea! Then your scheduled action doesn't have web exposure, only being triggered then saving data to the state lib. And your "display UI" action would have `web: yes` to return the data to the UI.

[duypnguyen]

@Urs_Boller, the alarms are run in UTC. Did you set your stopDate in UTC?

[Urs_Boller]

@duypnguyen here is my current setting:

          start-date: "2020-08-31T11:00:00.000Z"
          stop-date: "2020-08-31T12:00:00.000Z"

so the interval should have run only for 1 hour .... and I knwo I entered the start time the right way (but it started before...)
what are the right params for start and stop? 

[duypnguyen]

hi @Urs_Boller  - here are my test values. Worked fine.

startDate: "2020-08-31T14:20:00.000Z"
stopDate: "2020-08-31T14:22:00.000Z"

[Urs_Boller]

@duypnguyen thanks for the params, need to write them the right way! will give it a try. I will close the question as I think it will work