openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erez Hadad" <ER...@il.ibm.com>
Subject Re: Re: Passing TransactionId as part of action invocation
Date Mon, 19 Aug 2019 09:02:10 GMT
Hi folks,

My two cents: recall my "shared context" presentation about using a 
semi-transparent execution context that is shared across multiple 
consequent invocations. Similar to the transaction id being discussed. 
https://cwiki.apache.org/confluence/download/attachments/74689638/Shared%20Context%20in%20OpenWhisk%20Invocations.pptx?api=v2

Specifically, you may want to consider the implementation options in slide 
11:
1. One particular option of interest is to embed the shared context id ( = 
transaction id) in the activation id. When the new activation id is 
generated, the transaction id can be taken from the caller's activation id 
and embedded in the new activation id. This way the activation id remains 
unique per invocation but the transaction id can be extracted from it if 
needed, manually or via a client library (e.g., extending the OW js 
library). Kind of a minimal change. 
2. Another possibly valuable option is to have the transaction id used as 
a key for retrieving data (e.g., key/value) from a 3rd-party fast service, 
such as redis. This can be left open for the user of the transaction id or 
provide a reference implementation in the client library. Such data can 
also be pre-fetched before the invocation starts (e.g., from CouchDB / 
Redis), but again, at the cost of a higher code change.

Regards,
-- Erez






From:   Rodric Rabbah <rodric@gmail.com>
To:     dev@openwhisk.apache.org
Cc:     tyson.norris@gmail.com
Date:   17/08/2019 03:36
Subject:        [EXTERNAL] Re: Passing TransactionId as part of action 
invocation



Of course if the transaction id is the same as the activation id (of the 
composite action) the solutions are comparable. 

The downside of using transaction id is that we have no APIs to query by 
it today, and it?s not recorded in the activation metadata. So while it?s 
useful for external tracing (no objections to doing it), I think from an 
openwhisk API point of view we still have a gap. 

-r

On Aug 16, 2019, at 4:58 PM, Chetan Mehrotra <chetan.mehrotra@gmail.com> 
wrote:

>> I think if OW SDK, and sequences/compositions, propagate X-Request-Id
>> header (using the existing transaction id/X-Request-Id), the parent is 
not
>> needed?
> 
> Thats what I counting on as we just need to correlate calls made for a
> given flow corelated with time to get a sequence of flow.
> 
>> - expose the transaction id to runtime container
>> - propagate the transaction id in requests initiated from runtime
>> container/controller
> 
> Makes sense. Would open a ticket capturing these changes then
> Chetan Mehrotra
> 
>> On Fri, Aug 16, 2019 at 7:44 AM Tyson Norris <tysonnorris@gmail.com> 
wrote:
>> 
>> I think if OW SDK, and sequences/compositions, propagate X-Request-Id
>> header (using the existing transaction id/X-Request-Id), the parent is 
not
>> needed? i.e. there may be 2 parts to this effort:
>> - expose the transaction id to runtime container
>> - propagate the transaction id in requests initiated from runtime
>> container/controller
>> 
>> 
>> 
>>> On Thu, Aug 15, 2019 at 10:38 AM Rodric Rabbah <rodric@gmail.com> 
wrote:
>>> 
>>> In general yes but I think generally do you need the transaction id or 
the
>>> parent id for an activation?
>>> 
>>> This issue is relevant - 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk_issues_3083&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Oo9B0p_tCCWIIum5GpjjqA&m=RVvqHH3EKTdA9cNFz3n2dPeXV_wFUOU01I5vxvAqt8Q&s=eZzttWaoeE0WFe_MndFO1O6K1wA9hZbc-BKbRZa6kDM&e=

.
>>> I also recall in the early days of the composer, we wanted a way to 
query
>>> parent/child activations but this requires new couch views and we 
didn't
>>> pursue it.
>>> 
>>> 
>>> 
>>> On Thu, Aug 15, 2019 at 1:20 PM Chetan Mehrotra 
<chetan.mehrotra@gmail.com
>>>> 
>>> wrote:
>>> 
>>>> Currently we pass the `activation_id` as part of `/run` call to any
>>>> action runtime [1]. Would it be fine to also pass the `TransactionId`
>>>> such that it can be accessed by action code?
>>>> 
>>>> One usecase of this would be to enable tracing a sequence/composition
>>>> by linking all activations which are part of same transaction in
>>>> epsagon [2]
>>>> 
>>>> Chetan Mehrotra
>>>> [1]
>>>> 
>>> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_openwhisk_blob_master_docs_actions-2Dnew.md-23activation&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Oo9B0p_tCCWIIum5GpjjqA&m=RVvqHH3EKTdA9cNFz3n2dPeXV_wFUOU01I5vxvAqt8Q&s=-vjUf19hoPEdgOTjnbs7jjHFqsJhWIRJjQSQYIme8xw&e=


>>>> [2]
>>>> 
>>> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__epsagon.com_blog_epsagon-2Dmakes-2Dtroubleshooting-2Dapache-2Dopenwhisk-2Da-2Dsnap_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Oo9B0p_tCCWIIum5GpjjqA&m=RVvqHH3EKTdA9cNFz3n2dPeXV_wFUOU01I5vxvAqt8Q&s=IkGq6vR80pwlGlaXAkXHi_rV14IXnX0hc3smCWO8BM8&e=


>>>> 
>>> 





Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message