I mean, unless you're using these correlation ids in your business
logic, I don't see the problem of storing them in the database. My own
thoughts on using this feature would all be diagnostics-related. I'm
not running any non-trivial functions, though.
On Tue, 20 Aug 2019 at 05:30, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote:
>
> Hi Team,
>
> Branching the thread [1] to discuss how to record some metadata
> related to activation. Based on some of the usecases I see a need to
> record some more metadata related to activation. Some examples are
>
> 1. transactionId - Record the transactionId for which the activation is part
> of
> 2. pod name - Records the pod running the action container when using
> KubernetesContainerFactory
> 3. invocationId - Some id returned by underlying system when
> integrating with AWS Lambda or Azure Function
> 4. clusterId - If running multiple clusters for same system we would
> like to know which cluster handed the given execution
>
> Some of these ids are determined as part of `ContainerResponse` itself
> and have to be made part of activation json such that later we can
> correlate the activation with other parts.
>
> Now we need to determine how to store such id
>
> Option 1 - New "meta" sub document
> -----------
>
> Introduce a new "meta" key in activation json under which we store such ids
>
> "meta" : {
> "transactionId" : "xxx",
> "podId" : "ow_xxx"
> }
>
>
> Option 2 - Store them as annotations
> -------------
>
> Instead of introducing a new field we store them as annotations. Note
> we still make change in code to capture such data as part of
> `ContainerResponse` but just map it to annotations
>
> One drawback of this approach is that current approach of annotations
> make it harder to index such fields easily. Having a flat structure
> like with "meta" field enables indexing such fields in db's other than
> Couch
>
> Chetan Mehrotra
> [1]:
> https://lists.apache.org/thread.html/f8b73a9ffb0d09a50aecfb54538da2e8365c54dcc3e26a78382ad7bd@%3Cdev.openwhisk.apache.org%3E
--
Matt Sicker <boa...@gmail.com>
