namespace is not required in wskprops

[alexkli]

Originally reported by @ddragosd:

This OpenWhisk PR apache/openwhisk-cli#434 removed this.

This is also referenced in https://lists.apache.org/thread.html/cb315e7e7c3fcaa419aae67e1b00e7aafe94c7e2af09b71fd4ce68bb@%3Cdev.openwhisk.apache.org%3E

We can probably fetch it dynamically.

[alexkli]

Query for affected code

If fetching it dynamically, it should probably happen after this line and then set this.wskProps.namespace, from which all other places take it later.

[alexkli]

@ddragosd did you see an actual error?

When I tried this, the only thing that seems to be off is that wskdebug logs slightly wrong:

Starting debugger for /undefined/wskdebug-examples/webaction

Note the undefined instead of the correct namespace name.

But it still runs fine. It seems that if no namespace is given, openwhisk figures out the namespace itself, and that actually trickles down everywhere.

Versions used:

• npm openwhisk version 3.19.0
• wsk version 2019-03-20T20:17:38.064+0000
• openwhisk - tested against both old 2018-01-29T18:32:59Z and newer 2019-08-01 - a

[alexkli]

Ok, I can see a potential issue because of this line:

wskdebug/src/invoker.js

Line 233 in 6ef5bfe

action_name : `/${this.wskProps.namespace}/${this.actionName}`,

The action_name here is turned into the __OW_ACTION_NAME environment variable available inside the container. This must have the correct namespace in case an action is parsing this.

[alexkli]

Fixed in 7959a67.

I simply update the this.wskProps.namespace field that is used internally by wskdebug. This does not change the this.wsk instance of openwhisk(), because this would be a chicken and egg scenario, where I had to use the first one only to get the namespace and then create another instance with the now known namespace. But as mentioned above, it seems to happily work without the namespace configured in the constructor.