This is an automated email from the ASF dual-hosted git repository.
bsalzano pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/openserverless-site.git
The following commit(s) were added to refs/heads/main by this push:
new 5c24bf2 chore: yet another fox for nuv and Nuvolaris replacement (#38)
5c24bf2 is described below
commit 5c24bf2b23f82c33b99b50215f1c07a512784dae
Author: Francesco Timperi Tiberi <[email protected]>
AuthorDate: Tue Oct 29 21:27:31 2024 +0100
chore: yet another fox for nuv and Nuvolaris replacement (#38)
---
.../installation/prereq/server/generic/_index.md | 2 +-
content/en/docs/reference/entities/_index.md | 2 +-
.../docs/reference/entities/annotations/_index.md | 16 ++++----
content/en/docs/reference/entities/feeds/_index.md | 46 +++++++++++-----------
.../en/docs/reference/entities/packages/_index.md | 44 ++++++++++-----------
.../docs/reference/entities/parameters/_index.md | 22 +++++------
.../docs/reference/entities/webactions/_index.md | 38 +++++++++---------
.../references/actions-actionloop/_index.md | 40 +++++++++----------
.../reference/references/actions-new/_index.md | 10 ++---
.../reference/references/naming-limits/_index.md | 2 +-
.../docs/reference/references/rest_api/_index.md | 16 ++++----
.../docs/reference/references/scheduler/_index.md | 2 +-
12 files changed, 120 insertions(+), 120 deletions(-)
diff --git a/content/en/docs/installation/prereq/server/generic/_index.md
b/content/en/docs/installation/prereq/server/generic/_index.md
index 03a96f7..136ca75 100644
--- a/content/en/docs/installation/prereq/server/generic/_index.md
+++ b/content/en/docs/installation/prereq/server/generic/_index.md
@@ -6,7 +6,7 @@ weight: 10
## Configure a generic Linux server to install OpenServerless
If you have access to a generic Linux server, to be able to install
-Nuvolaris it needs to:
+OpenServerless it needs to:
1. be accessible without a password with `ssh`
diff --git a/content/en/docs/reference/entities/_index.md
b/content/en/docs/reference/entities/_index.md
index 16fbc3a..0e5ba9f 100644
--- a/content/en/docs/reference/entities/_index.md
+++ b/content/en/docs/reference/entities/_index.md
@@ -1,7 +1,7 @@
---
title: Entities
---
-You can find more informations about Nuvolaris and OpenWhisk entities
+You can find more informations about OpenServerless and OpenWhisk entities
here:
- [Actions](#actions.adoc)
diff --git a/content/en/docs/reference/entities/annotations/_index.md
b/content/en/docs/reference/entities/annotations/_index.md
index 916d13c..1ffc51a 100644
--- a/content/en/docs/reference/entities/annotations/_index.md
+++ b/content/en/docs/reference/entities/annotations/_index.md
@@ -4,14 +4,14 @@ weigth: 40
---
# Annotations
-OpenWhisk and Nuvolaris actions, triggers, rules and packages
+OpenWhisk and OpenServerless actions, triggers, rules and packages
(collectively referred to as assets) may be decorated with
`annotations`. Annotations are attached to assets just like parameters
with a `key` that defines a name and `value` that defines the value. It
is convenient to set them from the command line interface (CLI) via
`--annotation` or `-a` for short.
-Rationale: Annotations were added to OpenWhisk and Nuvolaris to allow
+Rationale: Annotations were added to OpenWhisk and OpenServerless to allow
for experimentation without making changes to the underlying asset
schema. We had, until the writing of this document, deliberately not
defined what `annotations` are permitted. However as we start to use
@@ -19,7 +19,7 @@ annotations more heavily to impart semantic changes, it’s
important that
we finally start to document them.
The most prevalent use of annotations to date is to document actions and
-packages. You’ll see many of the packages in the OpenWhisk and Nuvolaris
+packages. You’ll see many of the packages in the OpenWhisk and OpenServerless
catalog carry annotations such as a description of the functionality
offered by their actions, which parameters are required at package
binding time, and which are invoke-time parameters, whether a parameter
@@ -31,7 +31,7 @@ its input arguments unmodified (e.g.,
`function main(args) { return args }`). This action may be useful for
logging input parameters for example as part of a sequence or rule.
- nuv action create echo echo.js \
+ ops action create echo echo.js \
-a description 'An action which returns its input. Useful for logging
input to enable debug/replay.' \
-a parameters '[{ "required":false, "description": "Any JSON entity"
}]' \
-a sampleInput '{ "msg": "Five fuzzy felines"}' \
@@ -82,7 +82,7 @@ The following annotations on an action are available.
- `provide-api-key`: This annotation may be attached to actions which
require an API key, for example to make REST API calls to the
- OpenWhisk and Nuvolaris host. For newly created actions, if not
+ OpenWhisk and OpenServerless host. For newly created actions, if not
specified, it defaults to a false value. For existing actions, the
absence of this annotation, or its presence with a value that is not
*falsy* (i.e., a value that is different from zero, null, false, and
@@ -101,7 +101,7 @@ in the system. The annotations are:
- `web-export`: Makes its corresponding action accessible to REST
calls *without* authentication. We call these [*web
actions*](#webactions.adoc) because they allow one to use OpenWhisk
- and Nuvolaris actions from a browser for example. It is important to
+ and OpenServerless actions from a browser for example. It is important to
note that the *owner* of the web action incurs the cost of running
them in the system (i.e., the *owner* of the action also owns the
activations record). The rest of the annotations described below
@@ -146,7 +146,7 @@ are:
only present for actions in a package binding.
- `kind`: the kind of action executed, and one of the support
- OpenWhisk and Nuvolaris runtime kinds.
+ OpenWhisk and OpenServerless runtime kinds.
- `limits`: the time, memory and log limits that this activation were
subject to.
@@ -163,7 +163,7 @@ Lastly, and in order to provide you with some performance
transparency,
activations also record:
- `waitTime`: the time spent waiting in the internal OpenWhisk and
- Nuvolaris system. This is roughly the time spent between the
+ OpenServerless system. This is roughly the time spent between the
controller receiving the activation request and when the invoker
provisioned a container for the action.
diff --git a/content/en/docs/reference/entities/feeds/_index.md
b/content/en/docs/reference/entities/feeds/_index.md
index 63c8917..4a7c12f 100644
--- a/content/en/docs/reference/entities/feeds/_index.md
+++ b/content/en/docs/reference/entities/feeds/_index.md
@@ -4,13 +4,13 @@ weight: 60
---
# Implementing feeds
-OpenWhisk and Nuvolaris support an open API, where any user can expose
+OpenWhisk and OpenServerless support an open API, where any user can expose
an event producer service as a **feed** in a **package**. This section
describes architectural and implementation options for providing your
own feed.
-This material is intended for advanced OpenWhisk and Nuvolaris users who
-intend to publish their own feeds. Most OpenWhisk and Nuvolaris users
+This material is intended for advanced OpenWhisk and OpenServerless users who
+intend to publish their own feeds. Most OpenWhisk and OpenServerless users
can safely skip this section.
# Feed Architecture
@@ -28,7 +28,7 @@ easiest and most attractive option for implementing
low-frequency feeds.
## Polling
-In the `Polling` pattern, we arrange for an OpenWhisk and Nuvolaris
+In the `Polling` pattern, we arrange for an OpenWhisk and OpenServerless
*action* to poll an endpoint periodically to fetch new data. This
pattern is relatively easy to build, but the frequency of events will of
course be limited by the polling interval.
@@ -45,7 +45,7 @@ polling, or to set up a push notification.
Feeds and triggers are closely related, but technically distinct
concepts.
-- OpenWhisk and Nuvolaris process **events** which flow into the
+- OpenWhisk and OpenServerless process **events** which flow into the
system.
- A **trigger** is technically a name for a class of events. Each
@@ -63,12 +63,12 @@ concepts.
# Implementing Feed Actions
-The *feed action* is a normal OpenWhisk and Nuvolaris *action*, but it
+The *feed action* is a normal OpenWhisk and OpenServerless *action*, but it
should accept the following parameters: \* **lifecycleEvent**: one of
‘CREATE’, ‘READ’, ‘UPDATE’, ‘DELETE’, ‘PAUSE’, or ‘UNPAUSE’. \*
**triggerName**: the fully-qualified name of the trigger which contains
events produced from this feed. \* **authKey**: the Basic auth
-credentials of the OpenWhisk and Nuvolaris user who owns the trigger
+credentials of the OpenWhisk and OpenServerless user who owns the trigger
just mentioned.
The feed action can also accept any other parameters it needs to manage
@@ -83,11 +83,11 @@ For example, assume the user has created a `mycloudant`
binding for the
`cloudant` package with their username and password as bound parameters.
When the user issues the following command from the CLI:
-`nuv trigger create T --feed mycloudant/changes -p dbName myTable`
+`ops trigger create T --feed mycloudant/changes -p dbName myTable`
then under the covers the system will do something equivalent to:
-`nuv action invoke mycloudant/changes -p lifecycleEvent CREATE -p triggerName
T -p authKey <userAuthKey> -p password <password value from mycloudant binding>
-p username <username value from mycloudant binding> -p dbName mytype`
+`ops action invoke mycloudant/changes -p lifecycleEvent CREATE -p triggerName
T -p authKey <userAuthKey> -p password <password value from mycloudant binding>
-p username <username value from mycloudant binding> -p dbName mytype`
The feed action named *changes* takes these parameters, and is expected
to take whatever action is necessary to set up a stream of events from
@@ -98,8 +98,8 @@ For the Cloudant *changes* feed, the action happens to talk
directly to
a *cloudant trigger* service we’ve implemented with a connection-based
architecture. We’ll discuss the other architectures below.
-A similar feed action protocol occurs for `nuv trigger delete`,
-`nuv trigger update` and `nuv trigger get`.
+A similar feed action protocol occurs for `ops trigger delete`,
+`ops trigger update` and `ops trigger get`.
# Implementing Feeds with Hooks
@@ -107,27 +107,27 @@ It is easy to set up a feed via a hook if the event
producer supports a
webhook/callback facility.
With this method there is *no need* to stand up any persistent service
-outside of OpenWhisk and Nuvolaris. All feed management happens
-naturally though stateless OpenWhisk and Nuvolaris *feed actions*, which
+outside of OpenWhisk and OpenServerless. All feed management happens
+naturally though stateless OpenWhisk and OpenServerless *feed actions*, which
negotiate directly with a third part webhook API.
When invoked with `CREATE`, the feed action simply installs a webhook
for some other service, asking the remote service to POST notifications
-to the appropriate `fireTrigger` URL in OpenWhisk and Nuvolaris.
+to the appropriate `fireTrigger` URL in OpenWhisk and OpenServerless.
The webhook should be directed to send notifications to a URL such as:
POST /namespaces/{namespace}/triggers/{triggerName}
The form with the POST request will be interpreted as a JSON document
-defining parameters on the trigger event. OpenWhisk and Nuvolaris rules
+defining parameters on the trigger event. OpenWhisk and OpenServerless rules
pass these trigger parameters to any actions to fire as a result of the
event.
# Implementing Feeds with Polling
-It is possible to set up an OpenWhisk and Nuvolaris *action* to poll a
-feed source entirely within OpenWhisk and Nuvolaris, without the need to
+It is possible to set up an OpenWhisk and OpenServerless *action* to poll a
+feed source entirely within OpenWhisk and OpenServerless, without the need to
stand up any persistent connections or external service.
For feeds where a webhook is not available, but do not need high-volume
@@ -145,7 +145,7 @@ steps when called for `CREATE`:
3. The feed action sets up a *rule* *T → pollMyService*.
This procedure implements a polling-based trigger entirely using
-OpenWhisk and Nuvolaris actions, without any need for a separate
+OpenWhisk and OpenServerless actions, without any need for a separate
service.
# Implementing Feeds via Connections
@@ -154,18 +154,18 @@ The previous 2 architectural choices are simple and easy
to implement.
However, if you want a high-performance feed, there is no substitute for
persistent connections and long-polling or similar techniques.
-Since OpenWhisk and Nuvolaris actions must be short-running, an action
+Since OpenWhisk and OpenServerless actions must be short-running, an action
cannot maintain a persistent connection to a third party . Instead, we
-must stand up a separate service (outside of OpenWhisk and Nuvolaris)
+must stand up a separate service (outside of OpenWhisk and OpenServerless)
that runs all the time. We call these *provider services*. A provider
service can maintain connections to third party event sources that
support long polling or other connection-based notifications.
The provider service should provide a REST API that allows the OpenWhisk
-and Nuvolaris *feed action* to control the feed. The provider service
-acts as a proxy between the event provider and OpenWhisk and Nuvolaris –
+and OpenServerless *feed action* to control the feed. The provider service
+acts as a proxy between the event provider and OpenWhisk and OpenServerless –
when it receives events from the third party, it sends them on to
-OpenWhisk and Nuvolaris by firing a trigger.
+OpenWhisk and OpenServerless by firing a trigger.
The connection-based architecture is the highest performance option, but
imposes more overhead on operations compared to the polling and hook
diff --git a/content/en/docs/reference/entities/packages/_index.md
b/content/en/docs/reference/entities/packages/_index.md
index 3e378ef..ffd2e98 100644
--- a/content/en/docs/reference/entities/packages/_index.md
+++ b/content/en/docs/reference/entities/packages/_index.md
@@ -4,17 +4,17 @@ weight: 50
---
# Using and creating packages
-In OpenWhisk and Nuvolaris, you can use packages to bundle together a
+In OpenWhisk and OpenServerless, you can use packages to bundle together a
set of related actions, and share them with others.
A package can include *actions* and *feeds*. - An action is a piece of
-code that runs on OpenWhisk and Nuvolaris. For example, the Cloudant
+code that runs on OpenWhisk. For example, the Cloudant
package includes actions to read and write records to a Cloudant
database. - A feed is used to configure an external event source to fire
trigger events. For example, the Alarm package includes a feed that can
fire a trigger at a specified frequency.
-Every OpenWhisk and Nuvolaris entity, including packages, belongs in a
+Every OpenWhisk and OpenServerless entity, including packages, belongs in a
*namespace*, and the fully qualified name of an entity is
`/namespaceName[/packageName]/entityName`. Refer to the [naming
guidelines](#reference.adoc#openwhisk-entities) for more information.
@@ -26,7 +26,7 @@ creating and sharing packages.
## Browsing packages
-Several packages are registered with OpenWhisk and Nuvolaris. You can
+Several packages are registered with OpenWhisk and OpenServerless. You can
get a list of packages in a namespace, list the entities in a package,
and get a description of the individual entities in a package.
@@ -34,7 +34,7 @@ and get a description of the individual entities in a package.
<!-- -->
- $ nuv package list /nuvolaris
+ $ ops package list /nuvolaris
packages
/nuvolaris/openai private
@@ -45,7 +45,7 @@ and get a description of the individual entities in a package.
<!-- -->
- $ nuv package get --summary /nuvolaris/openai
+ $ ops package get --summary /nuvolaris/openai
package /nuvolaris/openai
(parameters: none defined)
action /nuvolaris/openai/models
@@ -67,7 +67,7 @@ entity.
<!-- -->
- $ nuv action get --summary /nuvolaris/openai/chat
+ $ ops action get --summary /nuvolaris/openai/chat
action /nuvolaris/openai/chat: Returns a result based on parameters
OPENAI_API_HOST and OPENAI_API_KEY
(parameters: **OPENAI_API_HOST, **OPENAI_API_KEY)
@@ -90,14 +90,14 @@ example:
<!-- -->
- $ nuv package create custom
+ $ ops package create custom
ok: created package custom
1. Get a summary of the package.
<!-- -->
- $ nuv package get --summary custom
+ $ ops package get --summary custom
package /myNamespace/custom
(parameters: none defined)
@@ -114,7 +114,7 @@ Notice that the package is empty.
<!-- -->
- $ nuv action create custom/identity identity.js
+ $ ops action create custom/identity identity.js
ok: created action custom/identity
Creating an action in a package requires that you prefix the action name
@@ -125,7 +125,7 @@ contain only actions and can’t contain another package.
<!-- -->
- $ nuv package get --summary custom
+ $ ops package get --summary custom
package /myNamespace/custom
(parameters: none defined)
action /myNamespace/custom/identity
@@ -137,7 +137,7 @@ You can see the `custom/identity` action in your namespace
now.
<!-- -->
- $ nuv action invoke --result custom/identity
+ $ ops action invoke --result custom/identity
{}
You can set default parameters for all the entities in a package. You do
@@ -150,7 +150,7 @@ example:
<!-- -->
- $ nuv package update custom --param city Austin --param country USA
+ $ ops package update custom --param city Austin --param country USA
ok: updated package custom
1. Display the parameters in the package and action, and see how the
@@ -159,7 +159,7 @@ example:
<!-- -->
- $ nuv package get custom
+ $ ops package get custom
ok: got package custom
...
"parameters": [
@@ -174,7 +174,7 @@ example:
]
...
- $ nuv action get custom/identity
+ $ ops action get custom/identity
ok: got action custom/identity
...
"parameters": [
@@ -194,7 +194,7 @@ example:
<!-- -->
- $ nuv action invoke --result custom/identity
+ $ ops action invoke --result custom/identity
{
"city": "Austin",
"country": "USA"
@@ -206,7 +206,7 @@ example:
<!-- -->
- $ nuv action invoke --result custom/identity --param city Dallas --param
state Texas
+ $ ops action invoke --result custom/identity --param city Dallas --param
state Texas
{
"city": "Dallas",
"country": "USA",
@@ -216,16 +216,16 @@ example:
## Sharing a package
After the actions and feeds that comprise a package are debugged and
-tested, the package can be shared with all OpenWhisk and Nuvolaris
+tested, the package can be shared with all OpenWhisk and OpenServerless
users. Sharing the package makes it possible for the users to bind the
package, invoke actions in the package, and author OpenWhisk and
-Nuvolaris rules and sequence actions.
+OpenServerless rules and sequence actions.
1. Share the package with all users:
<!-- -->
- $ nuv package update custom --shared yes
+ $ ops package update custom --shared yes
ok: updated package custom
1. Display the `publish` property of the package to verify that it is
@@ -233,7 +233,7 @@ Nuvolaris rules and sequence actions.
<!-- -->
- $ nuv package get custom
+ $ ops package get custom
ok: got package custom
...
"publish": true,
@@ -250,7 +250,7 @@ is private, then all of its contents are also private.
<!-- -->
- $ nuv package get --summary custom
+ $ ops package get --summary custom
package /myNamespace/custom: Returns a result based on parameters city and
country
(parameters: *city, *country)
action /myNamespace/custom/identity
diff --git a/content/en/docs/reference/entities/parameters/_index.md
b/content/en/docs/reference/entities/parameters/_index.md
index f1dc552..0025383 100644
--- a/content/en/docs/reference/entities/parameters/_index.md
+++ b/content/en/docs/reference/entities/parameters/_index.md
@@ -42,14 +42,14 @@ from the `params` object in this example.
<!-- -->
- nuv action update hello hello.js
+ ops action update hello hello.js
1. Parameters can be provided explicitly on the command-line, or by
supplying a file containing the desired parameters
To pass parameters directly through the command-line, supply a key/value
pair to the `--param` flag:
-`nuv action invoke --result hello --param name Dorothy --param place Kansas`
+`ops action invoke --result hello --param name Dorothy --param place Kansas`
This produces the result:
@@ -74,7 +74,7 @@ Now the action expects a single `person` parameter to have
fields `name`
and `place`. If we invoke the action with a single `person` parameter
that is valid JSON:
- nuv action invoke --result hello -p person '{"name": "Dorothy", "place":
"Kansas"}'
+ ops action invoke --result hello -p person '{"name": "Dorothy", "place":
"Kansas"}'
The result is the same because the CLI automatically parses the `person`
parameter value into the structured object that the action now expects:
@@ -98,13 +98,13 @@ parameter so that the action defaults to the place “Kansas”:
To specify default parameters explicitly on the command-line, provide a
key/value pair to the `param` flag:
- nuv action update hello --param place Kansas
+ ops action update hello --param place Kansas
1. Invoke the action, passing only the `name` parameter this time.
<!-- -->
- nuv action invoke --result hello --param name Dorothy
+ ops action invoke --result hello --param name Dorothy
{
"payload": "Hello, Dorothy from Kansas"
@@ -119,7 +119,7 @@ specifying the parameter value at invocation time.
<!-- -->
- nuv action invoke --result hello --param name Dorothy --param place
"Washington, DC"
+ ops action invoke --result hello --param name Dorothy --param place
"Washington, DC"
{
"payload": "Hello, Dorothy from Washington, DC"
@@ -145,7 +145,7 @@ package and shows an action making use of it.
<!-- -->
- nuv package update MyApp --param name World
+ ops package update MyApp --param name World
1. Create an action in this package:
@@ -155,13 +155,13 @@ package and shows an action making use of it.
return {payload: "Hello, " + params.name};
}
- nuv action update MyApp/hello hello.js
+ ops action update MyApp/hello hello.js
1. Invoke the action, and observe the default package parameter in use:
<!-- -->
- nuv action invoke --result MyApp/hello
+ ops action invoke --result MyApp/hello
{
"payload": "Hello, World"
@@ -187,7 +187,7 @@ creating/updating them, and when invoking actions.
<!-- -->
- nuv action update hello hello.js
+ ops action update hello hello.js
1. Create a parameter file called `parameters.json` containing
JSON-formatted parameters:
@@ -204,7 +204,7 @@ creating/updating them, and when invoking actions.
<!-- -->
- nuv action invoke --result hello --param-file parameters.json
+ ops action invoke --result hello --param-file parameters.json
{
"payload": "Hello, Dorothy from Kansas"
diff --git a/content/en/docs/reference/entities/webactions/_index.md
b/content/en/docs/reference/entities/webactions/_index.md
index bddc64e..9d0908f 100644
--- a/content/en/docs/reference/entities/webactions/_index.md
+++ b/content/en/docs/reference/entities/webactions/_index.md
@@ -4,10 +4,10 @@ weight: 20
---
# Web Actions
-Web actions are OpenWhisk and Nuvolaris actions annotated to quickly
+Web actions are OpenWhisk and OpenServerless actions annotated to quickly
enable you to build web based applications. This allows you to program
backend logic which your web application can access anonymously without
-requiring an OpenWhisk and Nuvolaris authentication key. It is up to the
+requiring an OpenWhisk and OpenServerless authentication key. It is up to the
action developer to implement their own desired authentication and
authorization (i.e. OAuth flow).
@@ -30,13 +30,13 @@ You may create a *web action* `hello` in the package `demo`
for the
namespace `guest` using the CLI’s `--web` flag with a value of `true` or
`yes`:
- $ nuv package create demo
+ $ ops package create demo
ok: created package demo
- $ nuv action create demo/hello hello.js --web true
+ $ ops action create demo/hello hello.js --web true
ok: created action demo/hello
- $ nuv action get demo/hello --url
+ $ ops action get demo/hello --url
ok: got action hello
https://${APIHOST}/api/v1/web/guest/demo/hello
@@ -128,17 +128,17 @@ omitted from the headers.
It is important to be aware of the [response size
limit](#reference.adoc) for actions since a response that exceeds the
predefined system limits will fail. Large objects should not be sent
-inline through OpenWhisk and Nuvolaris, but instead deferred to an
+inline through OpenWhisk and OpenServerless, but instead deferred to an
object store, for example.
## Handling HTTP requests with actions
-An OpenWhisk and Nuvolaris action that is not a web action requires both
+An OpenWhisk and OpenServerless action that is not a web action requires both
authentication and must respond with a JSON object. In contrast, web
actions may be invoked without authentication, and may be used to
implement HTTP handlers that respond with *headers*, *statusCode*, and
*body* content of different types. The web action must still return a
-JSON object, but the OpenWhisk and Nuvolaris system (namely the
+JSON object, but the OpenWhisk and OpenServerless system (namely the
`controller`) will treat a web action differently if its result includes
one or more of the following as top level JSON properties:
@@ -181,7 +181,7 @@ as parameters to the action input argument. They are:
(matching stops after consuming the action extension).
4. `__ow_user` (type: string): the namespace identifying the OpenWhisk
- and Nuvolaris authenticated subject.
+ and OpenServerless authenticated subject.
5. `__ow_body` (type: string): the request body entity, as a base64
encoded string when content is binary or JSON object/array, or plain
@@ -360,7 +360,7 @@ qualified name of the action must include its package name,
which is
Action parameters are protected and treated as immutable. Parameters are
automatically finalized when enabling web actions.
- $ nuv action create /guest/demo/hello hello.js \
+ $ ops action create /guest/demo/hello hello.js \
--parameter name Jane \
--web true
@@ -377,7 +377,7 @@
annotation](#annotations.adoc#annotations-specific-to-web-actions) to
secure the web action. When the `require-whisk-auth` annotation is set
to `true`, the action will authenticate the invocation request’s Basic
Authorization credentials to confirm they represent a valid OpenWhisk
-and Nuvolaris identity. When set to a number or a case-sensitive string,
+and OpenServerless identity. When set to a number or a case-sensitive string,
the action’s invocation request must include a `X-Require-Whisk-Auth`
header having this same value. Secured web actions will return a
`Not Authorized` when credential validation fails.
@@ -389,11 +389,11 @@ generated as the `require-whisk-auth` annotation value.
When set to
other value, that value is used as the `require-whisk-auth` annotation
value.
- nuv action update /guest/demo/hello hello.js --web true --web-secure
my-secret
+ ops action update /guest/demo/hello hello.js --web true --web-secure
my-secret
or
- nuv action update /guest/demo/hello hello.js --web true -a
require-whisk-auth my-secret
+ ops action update /guest/demo/hello hello.js --web true -a
require-whisk-auth my-secret
curl https://${APIHOST}/api/v1/web/guest/demo/hello.json?name=Jane -X GET
-H "X-Require-Whisk-Auth: my-secret"
@@ -407,7 +407,7 @@ To disable a web action from being invoked via web API
(`https://APIHOST/api/v1/web/`), pass a value of `false` or `no` to the
`--web` flag while updating an action with the CLI.
- nuv action update /guest/demo/hello hello.js --web false
+ ops action update /guest/demo/hello hello.js --web false
## Raw HTTP handling
@@ -442,14 +442,14 @@ parameters and as JSON value in the HTTP request body:
Raw HTTP web actions are enabled via the `--web` flag using a value of
`raw`.
- nuv action create /guest/demo/hello hello.js --web raw
+ ops action create /guest/demo/hello hello.js --web raw
### Disabling raw HTTP handling
Disabling raw HTTP can be accomplished by passing a value of `false` or
`no` to the `--web` flag.
- nuv update create /guest/demo/hello hello.js --web false
+ ops update create /guest/demo/hello hello.js --web false
### Decoding binary body content from Base64
@@ -488,7 +488,7 @@ utilizing the saved artifact, and invoke the web action.
As an example, save the Node function as `decode.js` and execute the
following commands:
- $ nuv action create decode decode.js --web raw
+ $ ops action create decode decode.js --web raw
ok: created action decode
$ curl -k -H "content-type: application" -X POST -d "Decoded body"
https://${APIHOST}/api/v1/web/guest/default/decodeNode.json
{
@@ -532,7 +532,7 @@ OPTIONS requests.
Save the above function to `custom-options.js` and execute the following
commands:
- $ nuv action create custom-option custom-options.js --web true -a
web-custom-options true
+ $ ops action create custom-option custom-options.js --web true -a
web-custom-options true
$ curl https://${APIHOST}/api/v1/web/guest/default/custom-options.http
-kvX OPTIONS
< HTTP/1.1 200 OK
< Server: nginx/1.11.13
@@ -559,7 +559,7 @@ values through a package binding.
## Error Handling
-When an OpenWhisk and Nuvolaris action fails, there are two different
+When an OpenWhisk and OpenServerless action fails, there are two different
failure modes. The first is known as an *application error* and is
analogous to a caught exception: the action returns a JSON object
containing a top level `error` property. The second is a *developer
diff --git a/content/en/docs/reference/references/actions-actionloop/_index.md
b/content/en/docs/reference/references/actions-actionloop/_index.md
index 750af0e..4f4cdc9 100644
--- a/content/en/docs/reference/references/actions-actionloop/_index.md
+++ b/content/en/docs/reference/references/actions-actionloop/_index.md
@@ -20,7 +20,7 @@ programming language](https://golang.org/), originally
developed
specifically to support the [OpenWhisk and OpenServerless Go language
runtime](https://github.com/apache/openwhisk-runtime-go). However, it
was written in a generic way such that it has since been adopted to
-implement OpenWhisk and Nuvolaris runtimes for Swift, PHP, Python, Rust,
+implement OpenWhisk and OpenServerless runtimes for Swift, PHP, Python, Rust,
Java, Ruby and Crystal. Even though it was developed with compiled
languages in mind it works equally well with scripting languages.
@@ -168,7 +168,7 @@ change to one supporting `Ruby` as we continue in this
tutorial.
## Preparing the Docker environment
Our language runtime’s `Dockerfile` has the task of preparing an
-environment for executing OpenWhisk and Nuvolaris Actions. Using the
+environment for executing OpenWhisk and OpenServerless Actions. Using the
ActionLoop approach, we use a multistage Docker build to
1. derive our OpenWhisk and OpenServerless language runtime from an existing
@@ -182,7 +182,7 @@ ActionLoop approach, we use a multistage Docker build to
2. leverage the existing `openwhisk/actionlooop-v2` image on Docker Hub
from which we will “extract” the *ActionLoop* proxy (i.e. copy
`/bin/proxy` binary) our runtime will use to process Activation
- requests from the OpenWhisk and Nuvolaris platform and execute
+ requests from the OpenWhisk and OpenServerless platform and execute
Actions by using the language’s tools and libraries from step \#1.
## Repurpose the renamed Python Dockerfile for Ruby builds
@@ -284,7 +284,7 @@ In Ruby, this can be rewritten as:
*Note that you are free to decide the path and filename for the
function’s source code. In our examples, we chose a base filename that
-includes the word `"main"` (since it is OpenWhisk and Nuvolaris’s
+includes the word `"main"` (since it is OpenWhisk and OpenServerless
default function name) and append two underscores to better assure
uniqueness.*
@@ -585,7 +585,7 @@ Here we will learn how to:
3. writing the validation tests
-4. testing the image in an actual OpenWhisk and Nuvolaris environment
+4. testing the image in an actual OpenWhisk and OpenServerless environment
### Entering in the test environment
@@ -645,7 +645,7 @@ one terminal type:
# results omitted for brevity ...
# (you should see a shell prompt of your image)
$ /bin/proxy -debug
- 2019/04/08 07:47:36 OpenWhisk and Nuvolaris ActionLoop Proxy 2: starting
+ 2019/04/08 07:47:36 OpenWhisk and OpenServerless ActionLoop Proxy 2:
starting
Now the runtime is started in debug mode, listening on port 8080, and
ready to accept Action deployments.
@@ -672,7 +672,7 @@ the `init` and `run` requests above.
The proxy’s debug output should appear something like:
/proxy # /bin/proxy -debug
- 2019/04/08 07:54:57 OpenWhisk and Nuvolaris ActionLoop Proxy 2: starting
+ 2019/04/08 07:54:57 OpenWhisk and OpenServerless ActionLoop Proxy 2:
starting
2019/04/08 07:58:00 compiler: /proxy/bin/compile
2019/04/08 07:58:00 it is source code
2019/04/08 07:58:00 compiling: ./action/16/src/exec main: hello
@@ -761,7 +761,7 @@ Now compile and examine the results again:
If we have reached this point in the tutorial, the runtime is able to
run and execute a simple test action. Now we need to validate the
runtime against a set of mandatory tests both locally and within an
-OpenWhisk and Nuvolaris staging environment. Additionally, we should
+OpenWhisk and OpenServerless staging environment. Additionally, we should
author and automate additional tests for language specific features and
styles.
@@ -854,7 +854,7 @@ image to Docker Hub with `make push`.
To run this test you need to configure access to OpenWhisk and OpenServerless
with `ops`. A simple way is to get access is to register a free account
in the IBM Cloud but this works also with our own deployment of
-OpenWhisk and Nuvolaris.
+OpenWhisk and OpenServerless.
Edit the Makefile as we did previously:
@@ -871,13 +871,13 @@ real thing”.
Test single:
$ make test-single
- nuv action update hello-demo-ruby hello.rb --docker
docker.io/linus/actionloop-demo-ruby-v2.6:latest --main hello
+ ops action update hello-demo-ruby hello.rb --docker
docker.io/linus/actionloop-demo-ruby-v2.6:latest --main hello
ok: updated action hello-demo-ruby
- nuv action invoke hello-demo-ruby -r
+ ops action invoke hello-demo-ruby -r
{
"greeting": "Hello stranger!"
}
- nuv action invoke hello-demo-ruby -p name Mike -r
+ ops action invoke hello-demo-ruby -p name Mike -r
{
"greeting": "Hello Mike!"
}
@@ -888,13 +888,13 @@ Test source zip:
zip src.zip main.rb hello.rb
adding: main.rb (deflated 42%)
adding: hello.rb (deflated 42%)
- nuv action update hello-demo-ruby src.zip --docker
docker.io/linus/actionloop-demo-ruby-v2.6:latest
+ ops action update hello-demo-ruby src.zip --docker
docker.io/linus/actionloop-demo-ruby-v2.6:latest
ok: updated action hello-demo-ruby
- nuv action invoke hello-demo-ruby -r
+ ops action invoke hello-demo-ruby -r
{
"greeting": "Hello stranger!"
}
- nuv action invoke hello-demo-ruby -p name Mike -r
+ ops action invoke hello-demo-ruby -p name Mike -r
{
"greeting": "Hello Mike!"
}
@@ -903,13 +903,13 @@ Test binary ZIP:
$ make test-bin-zip
docker run -i actionloop-demo-ruby-v2.6:latest -compile main <src.zip
>bin.zip
- nuv action update hello-demo-ruby bin.zip --docker
docker.io/actionloop/actionloop-demo-ruby-v2.6:latest
+ ops action update hello-demo-ruby bin.zip --docker
docker.io/actionloop/actionloop-demo-ruby-v2.6:latest
ok: updated action hello-demo-ruby
- nuv action invoke hello-demo-ruby -r
+ ops action invoke hello-demo-ruby -r
{
"greeting": "Hello stranger!"
}
- nuv action invoke hello-demo-ruby -p name Mike -r
+ ops action invoke hello-demo-ruby -p name Mike -r
{
"greeting": "Hello Mike!"
}
@@ -977,5 +977,5 @@ You can verify tests are running properly with:
Big congratulations are in order having reached this point successfully.
At this point, our runtime should be ready to run on any OpenWhisk and
-Nuvolaris platform and also can be submitted for consideration to be
-included in the Apache OpenWhisk and Nuvolaris project.
+OpenServerless platform and also can be submitted for consideration to be
+included in the Apache OpenWhisk and OpenServerless project.
diff --git a/content/en/docs/reference/references/actions-new/_index.md
b/content/en/docs/reference/references/actions-new/_index.md
index 35ade7b..5adc4ce 100644
--- a/content/en/docs/reference/references/actions-new/_index.md
+++ b/content/en/docs/reference/references/actions-new/_index.md
@@ -191,10 +191,10 @@ object providing a new activation context and the input
parameters for
the function. There may be many activations of the same function against
the same proxy (viz. container). Currently, the activations are
guaranteed not to overlap — that is, at any given time, there is at most
-one request to `/run` from the OpenWhisk and Nuvolaris platform.
+one request to `/run` from the OpenWhisk and OpenServerless platform.
The route must accept a JSON object and respond with a JSON object,
-otherwise the OpenWhisk and Nuvolaris platform will treat the activation
+otherwise the OpenWhisk and OpenServerless platform will treat the activation
as a failure and proceed to destroy the container. The JSON object
provided by the platform follows the following schema:
@@ -212,7 +212,7 @@ provided by the platform follows the following schema:
- `value` is a JSON object and contains all the parameters for the
function activation.
-- `namespace` is the OpenWhisk and Nuvolaris namespace for the action
+- `namespace` is the OpenWhisk and OpenServerless namespace for the action
(e.g., `whisk-system`).
- `action_name` is the [fully qualified
@@ -231,7 +231,7 @@ The `value` is the function parameters. The rest of the
properties
become part of the activation context which is a set of environment
variables constructed by capitalizing each of the property names, and
prefixing the result with `__OW_`. Additionally, the context must define
-`__OW_API_HOST` whose value is the OpenWhisk and Nuvolaris API host.
+`__OW_API_HOST` whose value is the OpenWhisk and OpenServerless API host.
This value is currently provided as an environment variable defined at
container startup time and hence already available in the context.
@@ -244,7 +244,7 @@ activation](actions.md#understanding-the-activation-record).
activation error. The response from the handler must be a JSON object
with a single field called `error` describing the failure. The value of
the error field may be any valid JSON value. Should the proxy fail to
-respond with a JSON object, the OpenWhisk and Nuvolaris platform will
+respond with a JSON object, the OpenWhisk and OpenServerless platform will
treat the failure as an uncaught exception. These two failures modes are
distinguished by the value of the `response.status` in the activation
record which is `application error` if the proxy returned an `error`
diff --git a/content/en/docs/reference/references/naming-limits/_index.md
b/content/en/docs/reference/references/naming-limits/_index.md
index bdd9b5f..df477c3 100644
--- a/content/en/docs/reference/references/naming-limits/_index.md
+++ b/content/en/docs/reference/references/naming-limits/_index.md
@@ -81,7 +81,7 @@ style="text-align:
left;"><p><code>/myOrg/video/transcode</code></p></td>
</table>
You will be using this naming scheme when you use the OpenWhisk and
-Nuvolaris CLI, among other places.
+OpenServerless CLI, among other places.
### Entity names
diff --git a/content/en/docs/reference/references/rest_api/_index.md
b/content/en/docs/reference/references/rest_api/_index.md
index db50787..12d2bca 100644
--- a/content/en/docs/reference/references/rest_api/_index.md
+++ b/content/en/docs/reference/references/rest_api/_index.md
@@ -7,7 +7,7 @@ After your OpenWhisk and OpenServerlesss environment is
enabled, you can use
it with your web apps or mobile apps with REST API calls.
For more details about the APIs for actions, activations, packages,
-rules, and triggers, see the [OpenWhisk and Nuvolaris API
+rules, and triggers, see the [OpenWhisk and OpenServerless API
documentation](http://petstore.swagger.io/?url=https://raw.githubusercontent.com/openwhisk/openwhisk/master/core/controller/src/main/resources/apiv1swagger.json).
All the capabilities in the system are available through a REST API.
@@ -51,7 +51,7 @@ All APIs are protected with HTTP Basic authentication. You
can use the
authentication. The Basic authentication credentials are in the `AUTH`
property in your `~/.nuvprops` file, delimited by a colon. You can also
retrieve these credentials using the CLI running
-`nuv property get --auth`.
+`ops property get --auth`.
The following is an example that uses the [cURL](https://curl.haxx.se)
command tool to get the list of all packages in the `whisk.system`
@@ -90,13 +90,13 @@ allowed (that is, Access-Control-Allow-Methods is
**Attention:** Because OpenWhisk and OpenServerless currently supports only
one key per namespace, it is not recommended to use CORS beyond simple
experiments. Use [Web Actions](#webactions.adoc) to expose your actions
-to the public and not use the OpenWhisk and Nuvolaris authorization key
+to the public and not use the OpenWhisk and OpenServerless authorization key
for client applications that require CORS.
## Using the CLI verbose mode
The OpenWhisk and OpenServerless CLI is an interface to the OpenWhisk and
-Nuvolaris REST API. You can run the CLI in verbose mode with the flag
+OpenServerless REST API. You can run the CLI in verbose mode with the flag
`-v`, this will print truncated information about the HTTP request and
response. To print all information use the flag `-d` for debug.
@@ -115,7 +115,7 @@ Let’s try getting the namespace value for the current user.
"Basic XXXYYYY"
],
"User-Agent": [
- "OpenWhisk and Nuvolaris-CLI/1.0 (2017-08-10T20:09:30+00:00)"
+ "OpenWhisk and OpenServerless-CLI/1.0 (2017-08-10T20:09:30+00:00)"
]
}
RESPONSE:Got response with code 200
@@ -140,7 +140,7 @@ string. The response is of content type `application/json`.
## Actions
**Note:** In the examples that follow, `$AUTH` and `$APIHOST` represent
-environment variables set respectively to your OpenWhisk and Nuvolaris
+environment variables set respectively to your OpenWhisk and OpenServerless
authorization key and API host.
To create or update an action send a HTTP request with method `PUT` on
@@ -221,7 +221,7 @@ on the action
-d
'{"namespace":"_","name":"hello","exec":{"kind":"nodejs:6","code":"function
main(params) { return {payload:\"Hello
\"+params.name}}"},"annotations":[{"key":"web-export","value":true},{"key":"raw-http","value":false},{"key":"final","value":true}]}'
You can now invoke this action as a public URL with no OpenWhisk and
-Nuvolaris authorization. Try invoking using the web action public URL
+OpenServerless authorization. Try invoking using the web action public URL
including an optional extension such as `.json` or `.http` for example
at the end of the URL.
@@ -240,7 +240,7 @@ To create an action sequence, you need to create it by
providing the
names of the actions that compose the sequence in the desired order, so
the output from the first action is passed as input to the next action.
-$ nuv action create sequenceAction –sequence
+$ ops action create sequenceAction –sequence
/whisk-system/utils/split,/whisk-system/utils/sort
Create a sequence with the actions `/whisk-system/utils/split` and
diff --git a/content/en/docs/reference/references/scheduler/_index.md
b/content/en/docs/reference/references/scheduler/_index.md
index 1caf096..94ce1b4 100644
--- a/content/en/docs/reference/references/scheduler/_index.md
+++ b/content/en/docs/reference/references/scheduler/_index.md
@@ -48,7 +48,7 @@ To deploy an action and request a single execution
automatically via the OpenSer
`ops action create scheduled-action scheduled-action.py -a autoexec true`
-If we now print activation logs with nuv activation poll, we will see our
action execution log:
+If we now print activation logs with `ops activation poll`, we will see our
action execution log:
```bash
Activation: 'scheduled' (ebd532139a464e9d9532139a46ae9d8a)
