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: Passing TransactionId as part of action invocation
Date Thu, 22 Aug 2019 08:09:38 GMT
Here are a few more examples of "meta" information, other than transaction 
id.
- QoS (e.g., to affect scheduling)
- URL of specific log channel (e.g., to consolidate logs across a chain of 
invocations)
- Flow ID (e.g., for tracing)
- Debug flag (e.g., to enable step-into interactive debugging)

The common pattern - these data fields are all shared across a chain of 
invocations. The mechanism to support them (IMHO) should be being 
[semi-]transparently passing the data from caller to callee. This can be 
done whether the call is synchronous, asynchronous or via event trigger.

As for mapping "meta" fields to environment variables, if we're already 
adding one new env var (PR #4586), then we can have that env var serve as 
a key to a record containing all the meta data, which could be retrieved 
on-demand. 

Regards,
-- Erez






From:   Tyson Norris <tnorris@adobe.com.INVALID>
To:     "dev@openwhisk.apache.org" <dev@openwhisk.apache.org>
Date:   21/08/2019 20:09
Subject:        [EXTERNAL] Re: Passing TransactionId as part of action 
invocation



I think the point of transaction id in this case is to correlate multiple 
activations, similar to how a sequence works, but not relying on sequence 
as the mechanism for doing this. 

Today, if you launch many activations explicitly, e.g. using OW SDK in 
your nodejs action, they are not "related" to each other, and this would 
offer a way to work around that. Initially, just storing the transaction 
id, means that operators can create queries to stitch multiple activations 
that originated from the same request. It would also be possible to expose 
transaction id to users in the same way that activation id is using a 
first class API, maybe as part of the existing activation API, e.g. GET 
o/api/v1/namespaces/_/activations?tid=<transactionid>

Users can certainly use APIs wrong, but with decent documentation, I don't 
think this should dissuade us from providing the feature.

Thanks
Tyson

On 8/21/19, 8:16 AM, "Martin Henke" <martin.henke@web.de> wrote:

    Chetan,
 
    from an operational point of view I have some fear that we will 
confuse the user by making the transaction id visible as a second id 
besides the 
    activation id. 
    Some will certainly use it to fetch activation records and fail, which 
will lead to questions.
    Any thoughts from your side ?
 
    Regards,
    Martin
 
 
    > On 20. Aug 2019, at 12:32, Chetan Mehrotra 
<chetan.mehrotra@gmail.com> wrote:
    > 
    > I created a separate thread to discuss how to store such metadata 
related
    > to activation.
    > 
    > Current open PR #4586 only enables exposing the transactionId to 
env. It
    > does not make any attempt to store the transactionId currently. Once 
we
    > decide how such data should be stored then I can open PR for  the 
same
    > 
    > Chetan Mehrotra
    > 
    > 
    > On Mon, Aug 19, 2019 at 8:47 AM Rodric Rabbah <rodric@gmail.com> 
wrote:
    > 
    >> Yes indeed. Your pr already open I think is fine as is.
    >> 
    >> -r
    >> 
    >> On Aug 19, 2019, at 11:36 AM, Chetan Mehrotra 
<chetan.mehrotra@gmail.com>
    >> wrote:
    >> 
    >>>> That?s true. Time for api/v2...
    >>> 
    >>> This is now becoming a rabbit hole! What option should we use 
without
    >> going
    >>> for v2?
    >>> 
    >>> 1. Introduce a new "meta" sub document
    >>> 2. OR Change annotations to flat map while storing but transform 
that to
    >>> array based structure while returning to client
    >>> 
    >>> Chetan Mehrotra
    >>> 
    >>> 
    >>>> On Mon, Aug 19, 2019 at 7:15 AM Rodric Rabbah <rodric@gmail.com>

wrote:
    >>>> 
    >>>> 
    >>>>> However changing them now would cause compatibility
    >>>>> issue with various tooling out there which may be interpreting 
the
    >>>>> annotation per current design
    >>>> 
    >>>> That?s true. Time for api/v2... ?
    >> 
 
 





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