The following sections provide more details about the OpenWhisk system.
OpenWhisk actions, triggers, and rules belong in a namespace, and optionally a package.
Packages can contain actions and feeds. A package cannot contain another package, so package nesting is not allowed. Also, entities do not have to be contained in a package.
In IBM Cloud, an organization+space pair corresponds to a OpenWhisk namespace. For example, the organization BobsOrg
and space dev
would correspond to the OpenWhisk namespace /BobsOrg_dev
.
You can create your own namespaces if you're entitled to do so. The /whisk.system
namespace is reserved for entities that are distributed with the OpenWhisk system.
The fully qualified name of an entity is /namespaceName[/packageName]/entityName
. Notice that /
is used to delimit namespaces, packages, and entities.
If the fully qualified name has three parts: /namespaceName/packageName/entityName
, then the namespace can be entered without a prefixed /
; otherwise, namespaces must be prefixed with a /
.
For convenience, the namespace can be left off if it is the user's default namespace.
For example, consider a user whose default namespace is /myOrg
. Following are examples of the fully qualified names of a number of entities and their aliases.
Fully qualified name | Alias | Namespace | Package | Name |
---|---|---|---|---|
/whisk.system/cloudant/read | /whisk.system | cloudant | read | |
/myOrg/video/transcode | video/transcode | /myOrg | video | transcode |
/myOrg/filter | filter | /myOrg | filter |
You will be using this naming scheme when you use the OpenWhisk CLI, among other places.
The names of all entities, including actions, triggers, rules, packages, and namespaces, are a sequence of characters that follow the following format:
_
, @
, .
, -
.More precisely, a name must match the following regular expression (expressed with Java metacharacter syntax): \A([\w]|[\w][\w@ .-]*[\w@.-]+)\z
.
OpenWhisk has a few system limits, including how much memory an action can use and how many action invocations are allowed per minute.
Note: This default limits are for the open source distribution; production deployments like IBM Cloud Functions likely have higher limits. As an operator or developer you can change some of the limits using Ansible inventory variables.
The following table lists the default limits for actions.
limit | description | configurable | unit | default |
---|---|---|---|---|
timeout | a container is not allowed to run longer than N milliseconds | per action | milliseconds | 60000 |
memory | a container is not allowed to allocate more than N MB of memory | per action | MB | 256 |
logs | a container is not allowed to write more than N MB to stdout | per action | MB | 10 |
concurrent | no more than N activations may be submitted per namespace either executing or queued for execution | per namespace | number | 100 |
minuteRate | no more than N activations may be submitted per namespace per minute | per namespace | number | 120 |
codeSize | the maximum size of the action code | configurable, limit per action | MB | 48 |
parameters | the maximum size of the parameters that can be attached | not configurable, limit per action/package/trigger | MB | 1 |
result | the maximum size of the action result | not configurable, limit per action | MB | 1 |
429: TOO MANY REQUESTS
.--ulimit nofile=1024:1024
.--pids-limit 1024
.Triggers are subject to a firing rate per minute as documented in the table below.
limit | description | configurable | unit | default |
---|---|---|---|---|
minuteRate | no more than N triggers may be fired per namespace per minute | per user | number | 60 |
429: TOO MANY REQUESTS
.