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 10:51:45 GMT
Hi Rodric,

The term "transaction id" is ambiguous. It can be interpreted, for 
example, as a grouping label for a distributed transaction, not 
necessarily one that befits a sequential flow.
"Flow id" seems to be a clearer definition, and more generic, in the sense 
that a transaction can "ride" on a flow, just like all the other examples 
below.

My point in the list of examples below is that all these can be future 
enhancements, and they are all enabled by the basic mechanism of 
associating a flow with additional meta data. Thus, we should not restrict 
the design to only one particular use case such as transactions (which is 
what I understood "transaction id" to be at first).

-- Erez




From:   Rodric Rabbah <rodric@gmail.com>
To:     dev@openwhisk.apache.org
Date:   22/08/2019 13:20
Subject:        [EXTERNAL] Re: Passing TransactionId as part of action 
invocation




> 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)

Unlike the transaction id (flow id?), these are all properties that don?t 
exist today in the control plane. 

-r




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