The compose
command compiles composition code to a portable JSON format. The
deploy
command deploys JSON-encoded compositions. These commands are intended
as a minimal complement to the OpenWhisk CLI. The OpenWhisk CLI already has the
capability to configure, invoke, and delete compositions since these are just
OpenWhisk actions but lacks the capability to create composition actions. The
compose
and deploy
commands bridge this gap. They make it possible to deploy
compositions as part of the development cycle or in shell scripts. They do not
replace the OpenWhisk CLI however as they do not duplicate existing OpenWhisk
CLI capabilities.
compose
Usage:
compose composition.js [flags]
Flags:
--ast only output the ast for the composition
--file write output to a file next to the input file
--js output the conductor action code for the composition
-o FILE write output to FILE
-v, --version output the composer version
--debug LIST comma-separated list of debug flags (when using --js flag)
The compose
command takes a JavaScript module that exports a composition
object (for example demo.js) and compiles this object to a
portable JSON format on the standard output or in file.
compose demo.js -o demo.json
If the --ast
option is specified, the compose
command only outputs a JSON
representation of the Abstract Syntax Tree for the composition.
If the --js
option is specified, the compose
command outputs the conductor
action code for the composition instead of the generated JSON.
If the -o
option is used, the compose
command outputs to the specified file.
If the --file
option is specified, the compose
command outputs to a file
next to the input file with a .json
or .conductor.js
extension (if the
--js
option is specified).
deploy
Usage:
deploy composition composition.json [flags]
Flags:
-a, --annotation KEY=VALUE add KEY annotation with VALUE
-A, --annotation-file KEY=FILE add KEY annotation with FILE content
--apihost HOST API HOST
--apiversion VERSION API VERSION
--basic force basic authentication
--bearer force bearer token authentication
-i, --insecure bypass certificate checking
--kind KIND the KIND of the conductor action runtime
-l, --logsize LIMIT the maximum log size LIMIT in MB for the conductor action (default 10)
-m, --memory LIMIT the maximum memory LIMIT in MB for the conductor action (default 256)
-t, --timeout LIMIT the timeout LIMIT in milliseconds for the conductor action (default 60000)
-u, --auth KEY authorization KEY
-v, --version output the composer version
-w, --overwrite overwrite actions if already defined
--debug LIST comma-separated list of debug flags
The deploy
command deploys a JSON-encoded composition with the given name.
deploy demo demo.json -w
ok: created /_/authenticate,/_/success,/_/failure,/_/demo
The deploy
command synthesizes and deploys a conductor action that implements
the composition with the given name. It also deploys the composed actions for
which definitions are provided as part of the composition.
The deploy
command outputs the list of deployed actions or an error result. If
an error occurs during deployment, the state of the various actions is unknown.
The -w
option authorizes the deploy
command to overwrite existing
definitions. More precisely, it deletes the deployed actions before recreating
them. As a result, default parameters, limits, and annotations on preexisting
actions are lost.
The --logsize
option specifies the maximum log size for the conductor action.
The --memory
option specifies the maximum memory for the conductor action.
The --timeout
option specifies the timeout for the conductor action.
The --kind
option specifies the kind for the conductor action runtime. By
default, the nodejs:default
OpenWhisk runtime is used. The chosen runtime must
be based on Node.js. Other Node.js runtimes may or may not be compatible with
Composer.
The deploy
command implicitly annotates the deployed composition action with
the required conductor
annotations. Other annotations may be specified by
means of the flags:
-a, --annotation KEY=VALUE add KEY annotation with VALUE
-A, --annotation-file KEY=FILE add KEY annotation with FILE content
Like the OpenWhisk CLI, the deploy
command supports the following flags for
specifying the OpenWhisk instance to use:
--apihost HOST API HOST
-i, --insecure bypass certificate checking
-u, --auth KEY authorization KEY
In addition the deploy
command supports the flags:
--basic force basic authentication
--bearer force bearer token authentication
If the --apihost
flag is absent, the environment variable __OW_API_HOST
is
used in its place. If neither is available, the deploy
command extracts the
APIHOST
key from the whisk property file.
The apiversion
may be specified using the --apiversion
flag, or, if absent,
the APIVERSION
property of the whisk property file. If both are absent, the
default is assumed.
If the --insecure
flag is set or the environment variable __OW_IGNORE_CERTS
is set to true
, the deploy
command ignores SSL certificates validation
failures.
The default target namespace is the value of environment variable
__OW_NAMESPACE
if defined. If not, it is the value of the NAMESPACE
property
in the whisk property file if present. Otherwise, the default _
value is used.
If the --basic
flag is set, the deploy
command uses basic authentication. If
the --bearer
flag is set, the deploy
command uses bearer token
authentication. If neither flag is set, the deploy
command uses basic
authentication only if the default target namespace is _
. Setting both flags
is an error.
For basic authentication, the authentication key is obtained from the --auth
flag. If the --auth
flag is absent, the environment variable __OW_API_KEY
is
used in its place. If neither is available, the deploy
command extracts the
AUTH
key from the whisk property file.
For bearer token authentication, the token is either the value of the
environment variable __OW_APIGW_TOKEN
if defined or the value of property
APIGW_ACCESS_TOKEN
in the whisk property file.
The default path for the whisk property file is $HOME/.wskprops
. It can be
altered by setting the WSK_CONFIG_FILE
environment variable.
The --debug
flag takes a comma-separated list of debugging options.
The needle
option activates needle
verbose logging.
The needle<defaults>
option enables overriding needle
default parameters.
The specified defaults
must be be a json dictionary, as for example in:
deploy demo demo.json --debug 'needle<{"connection":"keep-alive","open_timeout":60000}>'