openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James W Dubee" <>
Subject Re: Feed Provider API v2?
Date Mon, 23 Oct 2017 15:07:43 GMT

Hello Carlos,

The CLI changes to invoker a trigger feed with a "READ" request when
getting a trigger should be doable. Have you thought about what the trigger
get output should look like when the associated feed supports a "READ"

James Dubee

From:	Carlos Santana <>
Date:	10/20/2017 06:52 PM
Subject:	Re: Feed Provider API v2?

Hi James

Me and Adnan [1] from my team started to look into this last week.

He implemented the lifecycle "READ" in the kafka feed action,
The feed action will be invoke in the similar manner as "CREATE" and
"DELETE" but only requiring the `auth` to be pass and of course the
`lifecycleEvent: READ` and the triggerName
You can see it here

The PR that introduce this is here:

if you have the kafka setup locally you can test it via invoking the action

But we want to provide this in the CLI also, so when you do a "wsk trigger
get mykafkatrigger" it will detect the annotation and do an extra request
to get the trigger info from the the provider.

He was going to do same API for alarms, and cloudant trigger to implement
the "READ" lifecycle
And then look for someone that knows the go CLI code to add the the extra
request to "trigger get"

Probably we need to doc this lifecycle in the

For the update the thinking is to use the same design.
To use a lifecycle "UPDATE" to the feed action to change the configuration

Also there is a need when an api key is revoke, to tell the feed provider
to update replace all the trigger with the old key, and use the new key


On Thu, Oct 19, 2017 at 10:39 AM James Thomas <> wrote:

> Users are running into limitations of the current feed provider API.
> we collect requirements, potentials solutions and work on an update to
> API to support some of the new features?
> Looking back through the Github issues, I've tried to capture high-level
> requirements and solutions that have already been identified, included
> below.
> *Requirements*
> ** Support retrieving state about triggers registered with provider*
> This is the most common requirement. Feed providers only support
> "CREATE/DELETE" operations. Users want to be able to retrieve current
> of triggers from the provider. For example, this would allow people to
> number of triggers left to fire when maxTriggers is defined.
> Related issues:




> ** Add "delete trigger after max" option to enable auto-removing triggers
> that won't be fired anymore. *
> Numerous feeds now support a "maxTriggers" to limit the number of trigger
> activations. What happens once this limit has been reached? There's been
> discussion about removing "dangling" triggers versus disabling and how to
> surface this to the user. Should this option be baked into the API?
> This is relevant for an update to the "alarm" package to support
> triggers.
> Related issues:


> ** Add support for updating feeds?*
> As the API only supports "create and "delete" operations, what happens
> someone needs to update a trigger feed, e.g. updating cron schedule for
> alarm package. This behaviour will left be left to the feed provider to
> define. Having to "delete then re-create" creates the potential for lost
> events.
> Related issues:

> *What other requirements do people have?*
> *Potential Solutions*
> ** Extend provider API with new operations.*
> Add support for STATUS and UPDATE operations in addition to CREATE and

> * *Add "health" or "status" action to feed packages*
> Would handle returning status for user registered triggers.

> *Next Steps*
> ** Gather more requirements/solutions*
> Hopefully people can do this on the mailing to come up with other
> requirements and solutions to enhance the feed provider API.
> ** Define a more feed provider API spec?*
> Existing documentation for the feed provider API is very short and
> informal. Would it be helpful to have a more official document as we move
> to a broader API? This would hopefully encourage others to create new
> providers.

> ** Update existing feed providers to support new features*
> If we can agree on an extended feed provider API, the existing packages
> be reviewed for updating where relevant.
> Hopefully this message can spark some discussion, feeds are a really
> important part of the openwhisk platform. I'm happy to also introduce
> on the video call next week?
> --
> Regards,
> James Thomas

  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message