openwhisk alarms not allowed on local environment | Community
Skip to main content
Urs_Boller
Community Advisor
Urs_BollerCommunity Advisor
Community Advisor
August 30, 2020
Solved

openwhisk alarms not allowed on local environment

  • August 30, 2020
  • 1 reply
  • 3348 views

I tried to add openwhisk alarms to my app using /whisk.system/alarms https://github.com/AdobeDocs/adobeio-runtime/blob/33d0979a45b9e35e8addaad7e97dfb00f8ea5e12/reference/prepackages.md 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?

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by duynguyen_adobe

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

 

1 reply

D
Adobe Employee
duynguyen_adobeAdobe EmployeeAccepted solution
Adobe Employee
August 31, 2020

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

 

    D
    Adobe Employee
    duynguyen_adobeAdobe Employee
    Adobe Employee
    August 31, 2020

    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

    Terms & ConditionsAccessibility statement

    Loading footer...