Hi Erez, As Rodric mentioned other properties currently do not exist in the control plane. Later if such properties are implemented then we can pass them also.
Currently for this change no major change was done. For any such future addition the work involved would be more around extracting the required property and make it part of the env map passed to `/run` command. Chetan Mehrotra On Thu, Aug 22, 2019 at 3:51 AM Erez Hadad <er...@il.ibm.com> wrote: > > 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 <rod...@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 > > >
