You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openwhisk.apache.org by GitBox <gi...@apache.org> on 2018/01/19 00:12:00 UTC

[GitHub] tardieu opened a new pull request #3202: Action compositions

tardieu opened a new pull request #3202: Action compositions
URL: https://github.com/apache/incubator-openwhisk/pull/3202
 
 
   This PR introduces a new type of actions called compositions. Compositions are a kind of sequences with dynamically computed steps. While the components of a sequence must be specified before invocation, components of a composition can be decided as the composition is running.
   
   Like the sequence implementation, the bulk of the composition implementation lies in the controller. It chains the invocations of the component actions in the composition. It keeps track of the execution state. It produces the final activation record for the composition invocation.
   
   In contrast with sequences and in an attempt to keep the changes contained in the controller code, a composition is not a new kind of action but rather a action with a marker annotation. This means no CLI changes for instance.
   
   A conductor action is an action with a defined ?conductor? annotation. The value of the annotation does not matter. For simplicity, sequences cannot be conductors. The annotation is ignored on sequences. But sequences may be components of a composition.
   
   Conductor actions drive the execution of compositions. A conductor action may either return a final result or a triplet { action, params, state }. In the latter case, the specified component action is invoked on the specified params object. Upon completion of this action the conductor action is reinvoked with a payload that combines the output of the action with the state returned by the previous conductor invocation. The composition result is the result of the final conductor invocation in the chain of invocations.
   
   A composition is therefore a sequence of invocations alternating invocations of the (fixed) conductor action with invocations of the dynamically specified components of the composition. In a sense, the conductor action acts as a scheduler that decodes and executes a sequential program. Conductor actions make it possible to support dynamic composition in OpenWhisk without committing to any particular execution model (e.g., finite state machines of one kind or another), or invocation conventions.
   
   Compositions may be nested, i.e, a step in a composition may itself be a composition. The controller recognizes this pattern and handles it efficiently.
   
   Like a sequence, one composition is materialized by one action. Creating a composition requires the definition of one conductor action. Deleting the composition consists in deleting the corresponding action. Like a sequence, a composition refers to the composed actions by name (i.e., by reference).
   
   The PR enables a much better implementation of the composer library for OpenWhisk (https://github.com/ibm-functions/composer) that offers faster performance, lower cost (no double billing), and dramatically improves usability. With this PR, a composition _is_ an action. There is no distinction between invoking a composition and an action. Both invocations returns an activation id that can be used to fetch the result of the execution of the action or composition. Both invocations can be blocking. Both can be web actions.
   
   As for sequences, there is a configurable upper bound on the length of a composition (number of steps). In contrast with sequences, the limit is assessed at run time, and the composition invocation is aborted if the limit is exceeded. An entitlement check verify that each composed action is accessible prior to its execution. A composition invocation like a sequence invocation counts as one invocation viz. throttling. In particular, a composition will not be aborted during execution due to throttling. Therefore a composition designed to have fewer steps than the limit will not abort due to quotas once it has started execution.
   
   This PR comes with unit tests for the controller as well as integration tests.
   
   Example:
   ```
   $ cat > increment.js
   function main({ value }) { return { value: value + 1 } }
   ^D
   
   $ cat > conductor.js
   function main(params) {
       switch (params.$step || 0) {
           case 0: delete params.$step; return { params, action: 'increment', state: { $step: 1 } }
           case 1: delete params.$step; return { params, action: 'increment', state: { $step: 2 } }
           case 2: delete params.$step; return params
       }
   }
   ^D
   
   $ wsk action update increment increment.js
   $ wsk action update conductor conductor.js -a conductor true
   
   $ wsk action invoke conductor -br -p value 3
   {
       "value": 5
   }
   ```
   This example demonstrates a simple composition with two increment steps. The progress of the execution is tracked via the `$step` field of the parameter object that is propagated from a conductor invocation to the next but hidden from the composed actions.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services