I neglected a "fix the docs" only approach: we can update the docs to say
the trigger name may use the implicit namespace, and that it's the provider
action's responsibility to resolve the namespace fully... which the current
openwhisk providers are doing anyway.
-r
On Wed, Feb 20, 2019 at 4:10 PM Rodric Rabbah <rod...@gmail.com> wrote:
> Hello,
>
> This email is related to event feeds - see [1] for a refresher.
>
> In looking through some code for the providers, I noticed that when a user
> creates an event feed, the request carries a trigger name that is not fully
> resolved.
>
> For example, when creating an alarm feed,
> wsk trigger create t --feed whisk.system/alarms/once ...
>
> The feed provider receives the following request:
> {
> "authKey":"...",
> "lifecycleEvent":"CREATE",
> "triggerName":"/_/t"
> }
>
> The trigger name isn't fully resolved as it uses the implicit/placeholder
> `_`. This means the feed handler has to resolve the namespace. It can do
> this by doing a lookup using the provided key against the openwhisk
> controller:
>
> GET https://apikey@apihostt/api/v1/namespaces
>
> In the providers I looked at, the namespace is being resolved another way:
> by using the __OW_NAMESPACE activation context value. This is OK as well
> but if we just treat the feed creation as an arbitrary API call, this won't
> work. So either the client has to resolve the trigger name fully, or the
> provider has to do it (or both?).
>
> I am contemplating a change to the feed specification to make the trigger
> name fully qualified (ie no underscore) and so clients must do this and
> providers can reject requests that don't conform.
>
> This is a solicitation for comments. I've created an issue as well
> https://github.com/apache/incubator-openwhisk/issues/4300
>
> [1]
> https://github.com/apache/incubator-openwhisk/blob/master/docs/feeds.md#implementing-feed-actions
>
> -r
>
