nim vs wsk
Information for OpenWhisk developers
Nimbella powers the “serverless computing” portion of its offering with a modified version of Apache OpenWhisk. If you’re familiar with the OpenWhisk platform, you’ll recognize many similarities and some differences in the Nimbella commands and concepts. We’ll cover some of them here.
In Nimbella, as in OpenWhisk, the unit of authorization is called a namespace. As in all OpenWhisk deployments, a namespace contains actions that are optionally grouped into packages.
OpenWhisk has additional entities called rules, triggers, routes (the “API gateway”), and activations. The nim
command supports these entities when used individually, but not as part of a project.
Using the Nimbella stack with an OpenWhisk installation
If you’re using wsk
with some other OpenWhisk installation and using nim
with the Nimbella stack, they will not interfere with each other. If you want to use wsk
with the Nimbella stack, you can, but you should set the environment variable WSK_CONFIG_FILE=$HOME/.nimbella/wskprops
so that wsk
will use it instead of the ~/.wskprops
. This does not affect nim
, which ignores WSK_CONFIG_FILE
. If you sometimes use wsk
with a different installation and sometimes with Nimbella, you have to change the environment accordingly.
Note: Although nim
uses the OpenWhisk Node.js client internally, it takes steps to nullify the effect of any __OW_*
variables in the environment to prevent collisions with other uses of the client.
Credential management commands in nim vs. wsk
The nim
command doesn’t read or write ~/.wskprops
the way the wsk
binary does but instead replaces it with a more flexible credential store. The nim
command does maintain the file ~/.nimbella/wskprops
in sync with the credential store. This file has the same format as ~/.wskprops
and applies to the currently selected namespace.
See Credential Management to Access Nimbella Namespaces.
Project commands in nim vs. wsk
Note that the project
command of nim
is not a replacement for the wsk
project. See About Nimbella Projects.
The project
deploy and project watch
commands can operate on a logical grouping of OpenWhisk entities as well as other types of resources.
See Project-Level Deployment Commands.
Entity management commands in nim vs. wsk
The action
, activation
, namespace
, package
, route
, rule
and trigger
commands in nim each manage the corresponding type of entity as defined by Apache OpenWhisk. The syntax for these seven commands approximates that of like-named commands of the wsk
binary provided by the Apache OpenWhisk project, except that route
is used in place of api. The implementation of these commands is derived from the Adobe I/O Runtime open source project.
See Entity Management Commands.
Using Whisk commands in switching namespaces
If you use the wsk
command in conjunction with nim, note that the file ~/.nimbella/wskprops (not ~/.wskprops) is updated on every switch of the target namespace via nim auth
. You can connect your wsk
to this Nimbella-maintained property file using the WSK_CONFIG_FILE
environment variable.
Working with other OpenWhisk hosts
Usually, a Nimbella developer has just one API host and all namespaces use the same one, but multiple API hosts can be accommodated as well.
- If all of your namespaces have unique names, if some are on different API hosts, the API host is automatically switched when you switch the namespace.
- If you happen to have identically named namespaces on different API hosts, then you must use the
--apihost
flag to disambiguate. Substitute the URL of your API host in the following examples.
Nimbella actions and OpenWhisk
The term action is used to denote a serverless function, following Apache OpenWhisk terminology, because the Nimbella stack builds on OpenWhisk. Actions are by default OpenWhisk web action, which means the action is publicly accessible via a URL unless the project is configured. See xxx for information about how to construct the URL for a web action.
In Nimbella, as in OpenWhisk, the unit of authorization is called a namespace. As in all OpenWhisk deployments, a namespace contains actions that are optionally grouped into packages. (OpenWhisk has additional entities called rules, triggers, routes (aka “API gateway”), and activations; the nim
command supports these individually but not as part of a project.
Going beyond OpenWhisk, a Nimbella namespace contains additional resources, such as object store buckets for web content and database instances, which are managed as part of the namespace. The Create a Nimbella Namespace section explains how to obtain your first namespace. The Create and Manage Multiple Namespaces section discusses how to obtain and manage additional namespaces.
Annotations by the Nimbella deployer
OpenWhisk supports annotations on actions and packages. The deployer generates an annotation of its own in each action and package that it deploys. See Deployer Recordkeeping.
Project configuration
Here are some notes for project.yml
configuration file modifiers if you’re familiar with OpenWhisk.
- The
webSecure
action modifier has the same semantics that--web-secure
has in thewsk action create
command in OpenWhisk. (Thenim action create
command does not offer a similar flag). It generates therequire-whisk-auth
annotation according to whether you specifyfalse
(the default), a string value (a secret you select) ortrue
.