You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by James Thomas <ja...@jamesthom.as> on 2017/10/19 14:39:35 UTC
Feed Provider API v2?
Users are running into limitations of the current feed provider API. Could
we collect requirements, potentials solutions and work on an update to the
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 state
of triggers from the provider. For example, this would allow people to
number of triggers left to fire when maxTriggers is defined.
Related issues:
https://github.com/apache/incubator-openwhisk/issues/1925
https://github.com/apache/incubator-openwhisk/issues/1398
https://github.com/apache/incubator-openwhisk-package-alarms/issues/86#issuecomment-325204467
https://github.com/apache/incubator-openwhisk/issues/471
** 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 "one-off"
triggers.
Related issues:
https://github.com/apache/incubator-openwhisk-package-alarms/issues/89
https://github.com/apache/incubator-openwhisk-package-alarms/issues/86#issuecomment-325204467
** Add support for updating feeds?*
As the API only supports "create and "delete" operations, what happens when
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:
https://github.com/apache/incubator-openwhisk/issues/1925
*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
DELETE.
https://github.com/apache/incubator-openwhisk/issues/1925
* *Add "health" or "status" action to feed packages*
Would handle returning status for user registered triggers.
https://github.com/apache/incubator-openwhisk/issues/1925#issuecomment-297727773
*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 feed
providers.
https://github.com/apache/incubator-openwhisk/blob/master/docs/feeds.md#implementing-feed-actions
** Update existing feed providers to support new features*
If we can agree on an extended feed provider API, the existing packages can
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 this
on the video call next week?
--
Regards,
James Thomas
Re: Feed Provider API v2?
Posted by Carlos Santana <cs...@gmail.com>.
Dubee
Adnan is looking into the go-CLI changes on how we show the output of
the two http requests, one for the get on the trigger entity and the other
to the lifecycle READ
He also looking into changes for nodejs library
There are intial PRs opened here:
go-CLI https://github.com/apache/incubator-openwhisk/pull/2893
client-js https://github.com/apache/incubator-openwhisk-client-js/pull/80
-- Carlos
On Wed, Oct 25, 2017 at 10:37 AM Carlos Santana <cs...@gmail.com>
wrote:
> James
> For max triggers was something introduce for alarms, now that
> maxtrigger default have being change from 1000 to infinite we have not
> seeing users having problems.
> I will propose we deprecate the maxTrigger field and instead work on some
> use cases, that will not required the need for max Triggers.
>
> Jason on my team is working on some enhancements for alarms package.
> For example
> 1. having a startDate and stopDate to cron
> 2. a runOnce trigger, where is trigger is only fired once on a specific
> date
> 3. interval today cron is not interval but at the hour mark, for example
> we have users requesting ability to fire a trigger every 12 minutes,
> starting at a specific date, and not fired after a certain date
>
> With this enhancement the need for maxTrigger field is not need it anymore
> in my opinion, also maxTrigger is not persistent across reboots of the feed
> provider.
>
> There is also another semi related feature of giving the ability in the
> CLI to build on top like a runOnce Action (wsk action invoke myaction
> --once --date $date)
>
> We can discuss today at the tech interchange this topic also.
> Here are some slides I jot down to illustrate in a single place what we
> are working on
> https://ibm.box.com/v/OpenWhisk-Feed-Management
> https://ibm.box.com/v/OpenWhisk-Alarms-Updates-Q4-17
>
> -- Carlos
>
>
> On Mon, Oct 23, 2017 at 11:44 AM James Thomas <jt...@gmail.com>
> wrote:
>
>> It's good to see parts of this are already being implemented.
>>
>> What about the "max triggers" issues that were raised?
>>
>> It will be important to properly document the changes to the API to allow
>> other people to implement providers.
>>
>>
>>
>> On 20 October 2017 at 23:52, Carlos Santana <cs...@gmail.com> wrote:
>>
>> > 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
>> > https://github.com/apache/incubator-openwhisk-package-
>> > kafka/blob/master/action/messageHubFeed.js#L23
>> > The PR that introduce this is here:
>> >
>> https://github.com/apache/incubator-openwhisk-package-kafka/pull/217/files
>> >
>> > if you have the kafka setup locally you can test it via invoking the
>> action
>> > directly
>> >
>> > 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 feed.md
>> >
>> > 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
>> >
>> > [1]: https://github.com/abaruni
>> >
>> >
>> >
>> > On Thu, Oct 19, 2017 at 10:39 AM James Thomas <ja...@jamesthom.as>
>> wrote:
>> >
>> > > Users are running into limitations of the current feed provider API.
>> > Could
>> > > we collect requirements, potentials solutions and work on an update to
>> > the
>> > > 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
>> > state
>> > > of triggers from the provider. For example, this would allow people to
>> > > number of triggers left to fire when maxTriggers is defined.
>> > >
>> > > Related issues:
>> > > https://github.com/apache/incubator-openwhisk/issues/1925
>> > > https://github.com/apache/incubator-openwhisk/issues/1398
>> > >
>> > > https://github.com/apache/incubator-openwhisk-package-
>> > alarms/issues/86#issuecomment-325204467
>> > > https://github.com/apache/incubator-openwhisk/issues/471
>> > >
>> > > ** 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
>> > "one-off"
>> > > triggers.
>> > > Related issues:
>> > >
>> https://github.com/apache/incubator-openwhisk-package-alarms/issues/89
>> > >
>> > > https://github.com/apache/incubator-openwhisk-package-
>> > alarms/issues/86#issuecomment-325204467
>> > >
>> > > ** Add support for updating feeds?*
>> > >
>> > > As the API only supports "create and "delete" operations, what happens
>> > when
>> > > 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:
>> > > https://github.com/apache/incubator-openwhisk/issues/1925
>> > >
>> > > *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
>> > > DELETE.
>> > > https://github.com/apache/incubator-openwhisk/issues/1925
>> > >
>> > > * *Add "health" or "status" action to feed packages*
>> > >
>> > > Would handle returning status for user registered triggers.
>> > >
>> > > https://github.com/apache/incubator-openwhisk/issues/
>> > 1925#issuecomment-297727773
>> > >
>> > > *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
>> > feed
>> > > providers.
>> > >
>> > >
>> https://github.com/apache/incubator-openwhisk/blob/master/docs/feeds.md#
>> > implementing-feed-actions
>> > >
>> > > ** Update existing feed providers to support new features*
>> > >
>> > > If we can agree on an extended feed provider API, the existing
>> packages
>> > can
>> > > 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
>> > this
>> > > on the video call next week?
>> > >
>> > > --
>> > > Regards,
>> > > James Thomas
>> > >
>> >
>>
>>
>>
>> --
>> Regards,
>> James Thomas
>>
>
Re: Feed Provider API v2?
Posted by Carlos Santana <cs...@gmail.com>.
James
For max triggers was something introduce for alarms, now that maxtrigger
default have being change from 1000 to infinite we have not seeing users
having problems.
I will propose we deprecate the maxTrigger field and instead work on some
use cases, that will not required the need for max Triggers.
Jason on my team is working on some enhancements for alarms package.
For example
1. having a startDate and stopDate to cron
2. a runOnce trigger, where is trigger is only fired once on a specific date
3. interval today cron is not interval but at the hour mark, for example we
have users requesting ability to fire a trigger every 12 minutes, starting
at a specific date, and not fired after a certain date
With this enhancement the need for maxTrigger field is not need it anymore
in my opinion, also maxTrigger is not persistent across reboots of the feed
provider.
There is also another semi related feature of giving the ability in the CLI
to build on top like a runOnce Action (wsk action invoke myaction --once
--date $date)
We can discuss today at the tech interchange this topic also.
Here are some slides I jot down to illustrate in a single place what we are
working on
https://ibm.box.com/v/OpenWhisk-Feed-Management
https://ibm.box.com/v/OpenWhisk-Alarms-Updates-Q4-17
-- Carlos
On Mon, Oct 23, 2017 at 11:44 AM James Thomas <jt...@gmail.com> wrote:
> It's good to see parts of this are already being implemented.
>
> What about the "max triggers" issues that were raised?
>
> It will be important to properly document the changes to the API to allow
> other people to implement providers.
>
>
>
> On 20 October 2017 at 23:52, Carlos Santana <cs...@gmail.com> wrote:
>
> > 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
> > https://github.com/apache/incubator-openwhisk-package-
> > kafka/blob/master/action/messageHubFeed.js#L23
> > The PR that introduce this is here:
> >
> https://github.com/apache/incubator-openwhisk-package-kafka/pull/217/files
> >
> > if you have the kafka setup locally you can test it via invoking the
> action
> > directly
> >
> > 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 feed.md
> >
> > 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
> >
> > [1]: https://github.com/abaruni
> >
> >
> >
> > On Thu, Oct 19, 2017 at 10:39 AM James Thomas <ja...@jamesthom.as>
> wrote:
> >
> > > Users are running into limitations of the current feed provider API.
> > Could
> > > we collect requirements, potentials solutions and work on an update to
> > the
> > > 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
> > state
> > > of triggers from the provider. For example, this would allow people to
> > > number of triggers left to fire when maxTriggers is defined.
> > >
> > > Related issues:
> > > https://github.com/apache/incubator-openwhisk/issues/1925
> > > https://github.com/apache/incubator-openwhisk/issues/1398
> > >
> > > https://github.com/apache/incubator-openwhisk-package-
> > alarms/issues/86#issuecomment-325204467
> > > https://github.com/apache/incubator-openwhisk/issues/471
> > >
> > > ** 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
> > "one-off"
> > > triggers.
> > > Related issues:
> > > https://github.com/apache/incubator-openwhisk-package-alarms/issues/89
> > >
> > > https://github.com/apache/incubator-openwhisk-package-
> > alarms/issues/86#issuecomment-325204467
> > >
> > > ** Add support for updating feeds?*
> > >
> > > As the API only supports "create and "delete" operations, what happens
> > when
> > > 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:
> > > https://github.com/apache/incubator-openwhisk/issues/1925
> > >
> > > *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
> > > DELETE.
> > > https://github.com/apache/incubator-openwhisk/issues/1925
> > >
> > > * *Add "health" or "status" action to feed packages*
> > >
> > > Would handle returning status for user registered triggers.
> > >
> > > https://github.com/apache/incubator-openwhisk/issues/
> > 1925#issuecomment-297727773
> > >
> > > *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
> > feed
> > > providers.
> > >
> > >
> https://github.com/apache/incubator-openwhisk/blob/master/docs/feeds.md#
> > implementing-feed-actions
> > >
> > > ** Update existing feed providers to support new features*
> > >
> > > If we can agree on an extended feed provider API, the existing packages
> > can
> > > 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
> > this
> > > on the video call next week?
> > >
> > > --
> > > Regards,
> > > James Thomas
> > >
> >
>
>
>
> --
> Regards,
> James Thomas
>
Re: Feed Provider API v2?
Posted by James Thomas <jt...@gmail.com>.
It's good to see parts of this are already being implemented.
What about the "max triggers" issues that were raised?
It will be important to properly document the changes to the API to allow
other people to implement providers.
On 20 October 2017 at 23:52, Carlos Santana <cs...@gmail.com> wrote:
> 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
> https://github.com/apache/incubator-openwhisk-package-
> kafka/blob/master/action/messageHubFeed.js#L23
> The PR that introduce this is here:
> https://github.com/apache/incubator-openwhisk-package-kafka/pull/217/files
>
> if you have the kafka setup locally you can test it via invoking the action
> directly
>
> 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 feed.md
>
> 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
>
> [1]: https://github.com/abaruni
>
>
>
> On Thu, Oct 19, 2017 at 10:39 AM James Thomas <ja...@jamesthom.as> wrote:
>
> > Users are running into limitations of the current feed provider API.
> Could
> > we collect requirements, potentials solutions and work on an update to
> the
> > 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
> state
> > of triggers from the provider. For example, this would allow people to
> > number of triggers left to fire when maxTriggers is defined.
> >
> > Related issues:
> > https://github.com/apache/incubator-openwhisk/issues/1925
> > https://github.com/apache/incubator-openwhisk/issues/1398
> >
> > https://github.com/apache/incubator-openwhisk-package-
> alarms/issues/86#issuecomment-325204467
> > https://github.com/apache/incubator-openwhisk/issues/471
> >
> > ** 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
> "one-off"
> > triggers.
> > Related issues:
> > https://github.com/apache/incubator-openwhisk-package-alarms/issues/89
> >
> > https://github.com/apache/incubator-openwhisk-package-
> alarms/issues/86#issuecomment-325204467
> >
> > ** Add support for updating feeds?*
> >
> > As the API only supports "create and "delete" operations, what happens
> when
> > 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:
> > https://github.com/apache/incubator-openwhisk/issues/1925
> >
> > *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
> > DELETE.
> > https://github.com/apache/incubator-openwhisk/issues/1925
> >
> > * *Add "health" or "status" action to feed packages*
> >
> > Would handle returning status for user registered triggers.
> >
> > https://github.com/apache/incubator-openwhisk/issues/
> 1925#issuecomment-297727773
> >
> > *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
> feed
> > providers.
> >
> > https://github.com/apache/incubator-openwhisk/blob/master/docs/feeds.md#
> implementing-feed-actions
> >
> > ** Update existing feed providers to support new features*
> >
> > If we can agree on an extended feed provider API, the existing packages
> can
> > 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
> this
> > on the video call next week?
> >
> > --
> > Regards,
> > James Thomas
> >
>
--
Regards,
James Thomas
Re: Feed Provider API v2?
Posted by Carlos Santana <cs...@gmail.com>.
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
https://github.com/apache/incubator-openwhisk-package-kafka/blob/master/action/messageHubFeed.js#L23
The PR that introduce this is here:
https://github.com/apache/incubator-openwhisk-package-kafka/pull/217/files
if you have the kafka setup locally you can test it via invoking the action
directly
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 feed.md
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
[1]: https://github.com/abaruni
On Thu, Oct 19, 2017 at 10:39 AM James Thomas <ja...@jamesthom.as> wrote:
> Users are running into limitations of the current feed provider API. Could
> we collect requirements, potentials solutions and work on an update to the
> 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 state
> of triggers from the provider. For example, this would allow people to
> number of triggers left to fire when maxTriggers is defined.
>
> Related issues:
> https://github.com/apache/incubator-openwhisk/issues/1925
> https://github.com/apache/incubator-openwhisk/issues/1398
>
> https://github.com/apache/incubator-openwhisk-package-alarms/issues/86#issuecomment-325204467
> https://github.com/apache/incubator-openwhisk/issues/471
>
> ** 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 "one-off"
> triggers.
> Related issues:
> https://github.com/apache/incubator-openwhisk-package-alarms/issues/89
>
> https://github.com/apache/incubator-openwhisk-package-alarms/issues/86#issuecomment-325204467
>
> ** Add support for updating feeds?*
>
> As the API only supports "create and "delete" operations, what happens when
> 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:
> https://github.com/apache/incubator-openwhisk/issues/1925
>
> *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
> DELETE.
> https://github.com/apache/incubator-openwhisk/issues/1925
>
> * *Add "health" or "status" action to feed packages*
>
> Would handle returning status for user registered triggers.
>
> https://github.com/apache/incubator-openwhisk/issues/1925#issuecomment-297727773
>
> *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 feed
> providers.
>
> https://github.com/apache/incubator-openwhisk/blob/master/docs/feeds.md#implementing-feed-actions
>
> ** Update existing feed providers to support new features*
>
> If we can agree on an extended feed provider API, the existing packages can
> 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 this
> on the video call next week?
>
> --
> Regards,
> James Thomas
>
Re: Feed Provider API v2?
Posted by James W Dubee <jw...@us.ibm.com>.
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"
request?
Regards,
James Dubee
From: Carlos Santana <cs...@gmail.com>
To: dev@openwhisk.apache.org
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
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk-2Dpackage-2Dkafka_blob_master_action_messageHubFeed.js-23L23&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=kBbBQSHNmImWvCB9wSSjXcAasHWLHcu6-NjFa7Uvwd0&e=
The PR that introduce this is here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk-2Dpackage-2Dkafka_pull_217_files&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=_8msJotxQZ-bzYd--yeKYDMeZF0EycN-UuGGBYA49_c&e=
if you have the kafka setup locally you can test it via invoking the action
directly
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 feed.md
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
[1]:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_abaruni&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=YTGW5bpkDkrlz0h7JWdu6F6cy15WMSrg4GjSXNisZaI&e=
On Thu, Oct 19, 2017 at 10:39 AM James Thomas <ja...@jamesthom.as> wrote:
> Users are running into limitations of the current feed provider API.
Could
> we collect requirements, potentials solutions and work on an update to
the
> 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
state
> of triggers from the provider. For example, this would allow people to
> number of triggers left to fire when maxTriggers is defined.
>
> Related issues:
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk_issues_1925&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=dRoiYkv5BJw4HJTrGqeGJwO5lP-CXKsJ-hY_MQSqZvE&e=
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk_issues_1398&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=2E8U4ikXfanWzUha1bZ5ZZKMt1oyez3k0hwgvgfwreQ&e=
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk-2Dpackage-2Dalarms_issues_86-23issuecomment-2D325204467&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=HrBGPdF3yD2djMSZ9LbP037bdKxOqZPeRq3mt1IQAuY&e=
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk_issues_471&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=nJB61AyDiK3gKDspCC1MzsoL7A5dE-mq8YyCOfWiU0Q&e=
>
> ** 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
"one-off"
> triggers.
> Related issues:
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk-2Dpackage-2Dalarms_issues_89&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=6_78A__iz6XVgff3Hv28anlDeoL5YycUhOOAeVpAJp0&e=
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk-2Dpackage-2Dalarms_issues_86-23issuecomment-2D325204467&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=HrBGPdF3yD2djMSZ9LbP037bdKxOqZPeRq3mt1IQAuY&e=
>
> ** Add support for updating feeds?*
>
> As the API only supports "create and "delete" operations, what happens
when
> 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:
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk_issues_1925&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=dRoiYkv5BJw4HJTrGqeGJwO5lP-CXKsJ-hY_MQSqZvE&e=
>
> *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
> DELETE.
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk_issues_1925&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=dRoiYkv5BJw4HJTrGqeGJwO5lP-CXKsJ-hY_MQSqZvE&e=
>
> * *Add "health" or "status" action to feed packages*
>
> Would handle returning status for user registered triggers.
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk_issues_1925-23issuecomment-2D297727773&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=yZ5AC8k36l5aNEs1b7eAPQF94MajkVTu87e2O-ltK2Y&e=
>
> *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
feed
> providers.
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dopenwhisk_blob_master_docs_feeds.md-23implementing-2Dfeed-2Dactions&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=mNYL3iRkIHSpena7hJD92ihAR7Np-_j5HhizqqbvOHE&m=p5aKvZk1rW83hc0xAgbhBu8W7wIda-FcyeefWRdwmjs&s=rt-bepYYfb8pvqs2r3rv-OwFxxsbWT5BgDaQ59loosM&e=
>
> ** Update existing feed providers to support new features*
>
> If we can agree on an extended feed provider API, the existing packages
can
> 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
this
> on the video call next week?
>
> --
> Regards,
> James Thomas
>