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:
[email protected]


Reply via email to