Disable db record store for successful blocking activations

[selfxp]

This Issue is related to #4626 with the caveat that the blocking and successful activations should not be stored in the database at all.

The reason for this change is related to the fact that blocking and successful activations are usually never used after the response has been consumed.

The benefits can be measured in database performance, not storing blocking activations should improve write and search operations and it should cut down on the database storage cost on large-scale production environments.

Implementation details:

• Blocking and successful activations should not be stored in the database in case the config variable whisk.activation.disable-store-result is set to true. By default it would be set to false.
• Developers would still have the option of storing the blocking successful activations in the database in case X-OW-EXTRA-LOGGING is set to on in the invocation's request header.
• No changes to logging. Logs should still be available for all activations.
• No changes to metrics stored in Prometheus. Metrics provided by the user-events module should still be available for all activations.

Implementation side effects:

• wsk activation list won't display the list of blocking successful activations
• wsk activation get <activation_id> won't return the activation response.
• wsk activation logs <activation_id> will still be available. In case <activation_id> is known, it can be used to retrieve the activation logs.

[rabbah]

@selfxp can you clarify what you mean by wsk activation get won't return the activation response? Are you proposing dropping the entire response field from the activation record or is there more elided?

[selfxp]

@rabbah the proposal is to not store the activation record at all. This means that wsk activation get will return: The requested resource does not exist.

[rabbah]

Where do the logs come from then? In particular, No changes to logging. Logs should still be available for all activations. would not hold at least I don't see how to make this work and turn on this flag if using couch (vs an external logging service - which is fine, but I'm trying to clarify the design).

[selfxp]

yes, this would work only with external logging services: Splunk or Elasticsearch

[rabbah]

To also clarify further: Another capability lost is being able to look at activation execution times and warm/cold starts, error rates etc. This date is available in the events topic but not user visible.

Thanks for tagging me on the PR, will have a look.

[selfxp]

Yes, metadata for blocking successful activation won't be stored in the db, but it will be sent to the events topic.