[GitHub] [openwhisk] bdoyle0182 opened a new issue #4993: Feature Request: Operator Defined Activation Lifecycling Events

[GitBox <gi...@apache.org>]

bdoyle0182 opened a new issue #4993:
URL: https://github.com/apache/openwhisk/issues/4993


   Problem:
   
   Our openwhisk operation is strictly through a management orchestration layer built on top of openwhisk. We strictly use non-blocking activations, which requires us to get notification of when the activation completes. Otherwise we are stuck with polling the api to find out if the activation to see if the activation has completed, which doesn't scale. So our current implementation listens to the `events` topic to get notice that the activation has finished. We started out listening to the completed topics, but that no longer has all of the information we need so we listen to events now.
   
   The problem with this approach is that 1. the events topic produces lots of metrics that we just eat for this consumer and more importantly 2. it's a potential single bottleneck across all users / functions of the platform.
   
   Potential Solution:
   
   It would be nice if the invocation request could include some metadata about where to produce notice that the activation has completed. Or maybe it could be an annotation on the function itself. So each activation would have information on what kafka to produce the result to. Since we already produce the activation completion event to events, I don't think this should be too hard to accomplish. 
   
   For us at least, the way I envision it is each namespace would have a kafka topic to produce to to keep namespaces from potentially impacting each other. If it were to go that route, the user may not have to supply where to send the activation result and openwhisk just creates an activation topic for each namespace to produce completion acks to?
   
   I see this as being beneficial to anyone that leverages non-blocking activations and doesn't want to rely on a single topic for activation event notifications for the entire platform.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [openwhisk] style95 commented on issue #4993: Feature Request: Operator Defined Activation Lifecycling Events

[GitBox <gi...@apache.org>]

style95 commented on issue #4993:
URL: https://github.com/apache/openwhisk/issues/4993#issuecomment-707097804


   This generally looks good to me.
   And a couple of ideas came up.
   
   1. If you need a notification for non-blocking activation, why don't you use just blocking activation?
   Is this because the action runs for a long time, and the caller needs to work on other activities until the activation is over?
   
   2. I feel like, we need a feature similar to a callback.
   If so, I am inclined to have this functionality out of the platform.
   Instead of managing all stuff for notification, we can let users have their own notification channels.
   The platform can have a feature to call or send an event to the given channel.
   
   For example, a user can register his own notification callback URL or Kafka endpoints with a topic.
   Once activations are over, OpenWhisk will call the URL or send an event to the given Kafka.
   
   In this way, we can minimize the scope to manage.
   The failover or scalability of the channel would be managed in the scope of the external notification channel by users rather than the scope of OpenWhisk.
   
   How do you think?


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org