Closed woutersterp closed 3 years ago
@buggtb and @dgrove-oss do you have any input on this issue?
Hi. This seems like a correct analysis to me. Alarm.js should perhaps not be hardwiring https, but given that it does the $endpoint variable needs to not already have an https:// prefix.
Fixed in alarms package & fix included in 2.2.0 release of alarms. This issue should have been closed last summer.
Hi all,
We've been struggeling with getting the alarm provider up and running on one of our developer's pc. It seemed like a configuration error at first, but after finding out the cause of the problem, we think it has to do with commit d67925ba6a8953c68b7cf76a8e26cd4e5bd45e32 which is suppose to fix the SSL support on AWS.
The change in this commit has to do with changing the
WHISK_API_HOST
toWHISK_API_HOST_URL
, but the new value does not contain an hostname + port like the previous value, but contains the entire url (i.e. https://localhost:30031/).This causes problems with the installation of some packages like the alarm, since the alarm package prefixes the url with https://, as you can see in this file: https://github.com/apache/openwhisk-package-alarms/blob/master/action/alarm.js at line 37
To my understanding the change has been applied on too many places. The helm/openwhisk/configMapFiles/installPackages/myTask.sh file should not have been changed to use the WISK_API_HOST_URL