sven-lange-last commented on issue #4626: Allow limiting DB bloat by excluding response from Activation record in some cases URL: https://github.com/apache/openwhisk/issues/4626#issuecomment-532203874 Thanks for the proposal - it makes a lot of sense. We also see house-keeping problems with activations in CouchDB - we actually use Cloudant. A concept that fully removes activation documents from CouchDB after a retention period is complex and consumes a lot of CPU on the database cluster. In addition, a large amount of activation documents consumes a lot of space. As a consequence, storing activations can get pretty expensive if you run a large-scale production environment. When going forward with the proposal of not storing activations for blocking + successful + "not timed out on the front-end" invocations, we need to check with clients whether their existing workloads break with such a change. Migration and evolution of the system is always the challenge of running a public production environment. We had in mind to introduce a kind of activation store throttling - for example, only store a limited amount of activations per minute. This gives you a nice developer experience when starting with Openwhisk and for trying things out. But when running large production workloads, the workload owner would have to take care of storing action results - it's no more done by the platform. Your proposal with not storing blocking + successful + "not timed out" invocations has the big advantage that you will either receive activation results as result of your blocking activation or by explicitly asking for activation results. With activation store throttling, there are situations where the platform does not give you the activation result at all. Regarding the `ElasticSearchActivationStore` - we recently moved from an ELK based logging stack to LogDNA which bases on a different technology. That's why the `ElasticSearchActivationStore` is no more in focus for us. At the moment, we are storing activations to our databases as well as forwarding them to the client's LogDNA logging space. I think there are two valid strategies in this area: reducing the amount of activations as well as using better options for storing activations.
---------------------------------------------------------------- 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: us...@infra.apache.org With regards, Apache Git Services
