This is an automated email from the ASF dual-hosted git repository.
dubeejw pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-openwhisk.git
The following commit(s) were added to refs/heads/master by this push:
new ccac7d5 Fix typos in docs (#4279)
ccac7d5 is described below
commit ccac7d5131a80bddeb1b6dc0c6580051c90bc264
Author: James Dubee <[email protected]>
AuthorDate: Wed Feb 13 15:20:14 2019 -0500
Fix typos in docs (#4279)
* Fix typos in docs
* Re-word Docker paragraph
---
ansible/README.md | 8 ++++----
docs/about.md | 2 +-
docs/actions-docker.md | 2 +-
docs/actions-nodejs.md | 8 ++++----
docs/actions-swift.md | 2 +-
docs/actions.md | 6 +++---
docs/catalog.md | 2 +-
docs/cli.md | 2 +-
docs/deploy.md | 6 +++---
docs/mesos.md | 10 +++++-----
docs/metrics.md | 2 +-
docs/mobile_sdk.md | 2 +-
docs/parameters.md | 2 +-
docs/reference.md | 4 ++--
docs/spi.md | 16 ++++++++--------
tests/performance/README.md | 6 +++---
tools/admin/README-NEXT.md | 4 ++--
tools/build/README.md | 6 +++---
tools/db/README.md | 2 +-
tools/dev/README.md | 4 ++--
tools/macos/README.md | 2 +-
tools/macos/docker-machine/README.md | 2 +-
tools/ubuntu-setup/README.md | 2 +-
tools/vagrant/README.md | 8 ++++----
24 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/ansible/README.md b/ansible/README.md
index 13efbe9..16dc6fc 100644
--- a/ansible/README.md
+++ b/ansible/README.md
@@ -82,8 +82,8 @@ The following step must be executed once per development
environment.
It will generate the `hosts` configuration file based on your environment
settings.
The default configuration does not run multiple instances of core components
(e.g., controller, invoker, kafka).
-You may elect to enable high-availability (HA) mode by passing tne ansible
option `-e mode=HA` when executing this playbook.
-This will configure your deployment with multiple instances (e.g., two kafka
instancess, and two invokers).
+You may elect to enable high-availability (HA) mode by passing tne Ansible
option `-e mode=HA` when executing this playbook.
+This will configure your deployment with multiple instances (e.g., two Kafka
instances, and two invokers).
In addition to the host file generation, you need to configure the database
for your deployment. This is done
by modifying the file `ansible/db_local.ini` to provide the following
properties.
@@ -98,7 +98,7 @@ db_host=
db_port=
```
-This file is generated automatically for an ephermeral CouchDB instance during
`setup.yml`. If you want to use Cloudant, you have to modify the file.
+This file is generated automatically for an ephemeral CouchDB instance during
`setup.yml`. If you want to use Cloudant, you have to modify the file.
For convenience, you can use shell environment variables that are read by the
playbook to generate the required `db_local.ini` file as shown below.
```
@@ -220,7 +220,7 @@ cd "$OPENWHISK_HOME/../incubator-openwhisk-cli"
```
The binaries are generated and put into a tarball in the folder
-`../incubator-openwhisk-cli/release`. Then, use the following ansible command
+`../incubator-openwhisk-cli/release`. Then, use the following Ansible command
to (re-)configure the CLI installation:
```
diff --git a/docs/about.md b/docs/about.md
index 269f091..e0cd08c 100644
--- a/docs/about.md
+++ b/docs/about.md
@@ -65,7 +65,7 @@ What actually happens behind the scenes in OpenWhisk?
### Entering the system: nginx
-First: OpenWhisk’s user-facing API is completely HTTP based and follows a
RESTful design. As a consequence, the command sent via the wsk-CLI is
essentially an HTTP request against the OpenWhisk system. The specific command
above translates roughly to:
+First: OpenWhisk’s user-facing API is completely HTTP based and follows a
RESTful design. As a consequence, the command sent via the `wsk` CLI is
essentially an HTTP request against the OpenWhisk system. The specific command
above translates roughly to:
```
POST /api/v1/namespaces/$userNamespace/actions/myAction
Host: $openwhiskEndpoint
diff --git a/docs/actions-docker.md b/docs/actions-docker.md
index 79ffdc5..84ce543 100644
--- a/docs/actions-docker.md
+++ b/docs/actions-docker.md
@@ -105,7 +105,7 @@ The instructions that follow show you how to use the
OpenWhisk Docker skeleton.
Notice the use of `--docker` when creating an action. Currently all Docker
images are assumed
to be hosted on Docker Hub.
- *Note:* It is considered best-practice for production images to be versioned
via docker image tags. The absence of a tag will be treated the same as using
the tag "latest", which will guarantee to pull from the registry when creating
new containers. That contains the possibility of failing because pulling the
image fails. For tagged images however, the system will allow a failing pull
and gracefully recover it by using the image that is already locally available,
making it much more re [...]
+ *Note:* It is considered best-practice for production images to be versioned
via docker image tags. The absence of a tag will be treated the same as using a
"latest" tag, which will result in a pull from the registry when creating new
containers. Pulling an image may fail due to a network interruption or Docker
Hub outage. For tagged images however, the system will gracefully recover from
a failed pull by using the image that is already locally available, making it
much more resilient [...]
The "latest" tag should therefore only be used for rapid prototyping where
guaranteeing the latest code state is more important than runtime stability at
scale.
diff --git a/docs/actions-nodejs.md b/docs/actions-nodejs.md
index ad98f9a..df70294 100644
--- a/docs/actions-nodejs.md
+++ b/docs/actions-nodejs.md
@@ -143,7 +143,7 @@ This example invokes a Yahoo Weather service to get the
current conditions at a
```
Note that the action in the example uses the JavaScript `request` library to
make an HTTP request to the Yahoo Weather API, and extracts fields from the
JSON result.
- See the Javascript [reference](#reference) for the Node.js packages
available in the runtime environment.
+ See the JavaScript [reference](#reference) for the Node.js packages
available in the runtime environment.
This example also shows the need for asynchronous actions. The action
returns a Promise to indicate that the result of this action is not available
yet when the function returns. Instead, the result is available in the
`request` callback after the HTTP call completes, and is passed as an argument
to the `resolve()` function.
@@ -354,7 +354,7 @@ The following packages are available to be used in the
Node.js 6 environment:
- [moment v2.17.0](https://www.npmjs.com/package/moment) - A lightweight
JavaScript date library for parsing, validating, manipulating, and formatting
dates.
- [mongodb v2.2.11](https://www.npmjs.com/package/mongodb) - The official
MongoDB driver for Node.js.
- [mustache v2.3.0](https://www.npmjs.com/package/mustache) - Mustache.js is
an implementation of the mustache template system in JavaScript.
-- [nano v6.2.0](https://www.npmjs.com/package/nano) - Minimalistic couchdb
driver for Node.js.
+- [nano v6.2.0](https://www.npmjs.com/package/nano) - Minimalistic CouchDB
driver for Node.js.
- [node-uuid v1.4.7](https://www.npmjs.com/package/node-uuid) - Deprecated
UUID packaged.
- [nodemailer v2.6.4](https://www.npmjs.com/package/nodemailer) - Send e-mails
from Node.js – easy as cake!
- [oauth2-server v2.4.1](https://www.npmjs.com/package/oauth2-server) -
Complete, compliant, and well tested module for implementing an OAuth2
Server/Provider with express in Node.js.
@@ -373,14 +373,14 @@ The following packages are available to be used in the
Node.js 6 environment:
- [socket.io-client v1.6.0](https://www.npmjs.com/package/socket.io-client) -
Client-side support for Socket.IO.
- [superagent v3.0.0](https://www.npmjs.com/package/superagent) - SuperAgent
is a small progressive client-side HTTP request library, and Node.js module
with the same API, sporting many high-level HTTP client features.
- [swagger-tools v0.10.1](https://www.npmjs.com/package/swagger-tools) - Tools
that are related to working with Swagger, a way to document APIs.
-- [tmp v0.0.31](https://www.npmjs.com/package/tmp) - A simple temporary file
and directory creator for node.js.
+- [tmp v0.0.31](https://www.npmjs.com/package/tmp) - A simple temporary file
and directory creator for Node.js.
- [twilio v2.11.1](https://www.npmjs.com/package/twilio) - A wrapper for the
Twilio API, related to voice, video, and messaging.
- [underscore v1.8.3](https://www.npmjs.com/package/underscore) -
Underscore.js is a utility-belt library for JavaScript that supports the usual
functional suspects (each, map, reduce, filter...) without extending any core
JavaScript objects.
- [uuid v3.0.0](https://www.npmjs.com/package/uuid) - Simple, fast generation
of RFC4122 UUIDS.
- [validator v6.1.0](https://www.npmjs.com/package/validator) - A library of
string validators and sanitizers.
- [watson-developer-cloud
v2.29.0](https://www.npmjs.com/package/watson-developer-cloud) - Node.js client
library to use the Watson Developer Cloud services, a collection of APIs that
use cognitive computing to solve complex problems.
- [when v3.7.7](https://www.npmjs.com/package/when) - When.js is a rock solid,
battle-tested Promises/A+ and when() implementation, including a complete ES6
Promise shim.
-- [winston v2.3.0](https://www.npmjs.com/package/winston) - A multi-transport
async logging library for node.js. "CHILL WINSTON! ... I put it in the logs."
+- [winston v2.3.0](https://www.npmjs.com/package/winston) - A multi-transport
async logging library for Node.js. "CHILL WINSTON! ... I put it in the logs."
- [ws v1.1.1](https://www.npmjs.com/package/ws) - ws is a simple to use,
blazing fast, and thoroughly tested WebSocket client and server implementation.
- [xml2js v0.4.17](https://www.npmjs.com/package/xml2js) - Simple XML to
JavaScript object converter. It supports bi-directional conversion.
- [xmlhttprequest v1.8.0](https://www.npmjs.com/package/xmlhttprequest) -
node-XMLHttpRequest is a wrapper for the built-in http client to emulate the
browser XMLHttpRequest object.
diff --git a/docs/actions-swift.md b/docs/actions-swift.md
index 78d1bde..c54a043 100644
--- a/docs/actions-swift.md
+++ b/docs/actions-swift.md
@@ -119,7 +119,7 @@ The docker runtime includes a compiler to help users
compile and package Swift 4
### Compiling a single source file for Swift 4.2
-To compile a single source file that doesn't depend on external libaries you
can use the following command:
+To compile a single source file that doesn't depend on external libraries you
can use the following command:
```bash
docker run -i openwhisk/action-swift-v4.2 -compile main <hello.swift >hello.zip
```
diff --git a/docs/actions.md b/docs/actions.md
index 3153090..4c10e8e 100644
--- a/docs/actions.md
+++ b/docs/actions.md
@@ -280,7 +280,7 @@ ok: updated action greeting
Sometimes it is necessary or just convenient to provide values for function
parameters. These can serve as
defaults, or as a way of reusing an action but with different parameters.
Parameters can be bound to an action
-and unless overriden later by an invocation, they will provide the specified
value to the function.
+and unless overridden later by an invocation, they will provide the specified
value to the function.
Here is an example.
@@ -301,7 +301,7 @@ wsk action invoke greeting --result
}
```
-You may still provide additional parmaeters, as in the `place`:
+You may still provide additional parameters, as in the `place`:
```
wsk action invoke greeting --result --param place Kansas
{
@@ -320,7 +320,7 @@ wsk action invoke greeting --result --param place Kansas
--param name Dorothy
When an invocation request is received, the system records the request and
dispatches an activation.
-The system returns an activation ID (in the case of a nonblocking invocation)
to confirm that the invocation was received.
+The system returns an activation ID (in the case of a non-blocking invocation)
to confirm that the invocation was received.
Notice that if there's a network failure or other failure which intervenes
before you receive an HTTP response, it is possible
that OpenWhisk received and processed the request.
diff --git a/docs/catalog.md b/docs/catalog.md
index 97f55ac..a30ac97 100644
--- a/docs/catalog.md
+++ b/docs/catalog.md
@@ -28,7 +28,7 @@ The catalog is available as packages in the `/whisk.system`
namespace. See [Brow
| Package | Description |
| --- | --- |
|
[/whisk.system/alarms](https://github.com/apache/incubator-openwhisk-package-alarms/blob/master/README.md)
| Package to create periodic triggers |
-|
[/whisk.system/cloudant](https://github.com/apache/incubator-openwhisk-package-cloudant/blob/master/README.md)
| Package to work with [Cloudant noSQL
DB](https://console.ng.bluemix.net/docs/services/Cloudant/index.html) service |
+|
[/whisk.system/cloudant](https://github.com/apache/incubator-openwhisk-package-cloudant/blob/master/README.md)
| Package to work with [Cloudant NoSQL
DB](https://console.ng.bluemix.net/docs/services/Cloudant/index.html) service |
|
[/whisk.system/github](https://github.com/apache/incubator-openwhisk-catalog/blob/master/packages/github/README.md)
| Package to create webhook triggers for
[GitHub](https://developer.github.com/) |
|
[/whisk.system/messaging](https://github.com/apache/incubator-openwhisk-package-kafka/blob/master/README.md)
| Package to work with [Message
Hub](https://console.ng.bluemix.net/docs/services/MessageHub/index.html)
service |
|
[/whisk.system/pushnotifications](https://github.com/apache/incubator-openwhisk-package-pushnotifications/blob/master/README.md)
| Package to work with [Push
Notification](https://console.ng.bluemix.net/docs/services/mobilepush/index.html)
service |
diff --git a/docs/cli.md b/docs/cli.md
index f969307..901a7dd 100644
--- a/docs/cli.md
+++ b/docs/cli.md
@@ -110,7 +110,7 @@ The CLI can be setup to use an HTTPS proxy. To setup an
HTTPS proxy, an environm
The CLI has an extra level of security from client to apihost, system provides
default client certificate configuration which deployment process generated,
then you can refer to below steps to use client certificate:
* The client certificate verification is off default, you can configure
`nginx_ssl_verify_client` to `on` or `optional` to open it for your
corresponding environment configuration.
* Create your own client certificate instead of system provides if you want,
after created, you can configure `openwhisk_client_ca_cert` to your own ca cert
path for your corresponding environment configuration.
-* Run the follwing command to pass client certificate:
+* Run the following command to pass client certificate:
```
./bin/wsk property set --cert <client_cert_path> --key <client_key_path>
```
diff --git a/docs/deploy.md b/docs/deploy.md
index 5fef484..93cf05c 100644
--- a/docs/deploy.md
+++ b/docs/deploy.md
@@ -20,13 +20,13 @@ This page documents configuration options that should be
considered when deployi
# Controller Clustering
-The system can be configured to use Akka clustering to manage the distributed
state of the Contoller's load balancing algorithm. This imposes the following
constraints on a deployment
+The system can be configured to use Akka clustering to manage the distributed
state of the Controller's load balancing algorithm. This imposes the following
constraints on a deployment
## Cluster setup
To setup a cluster, the controllers need to be able to discover each other.
There are 2 basic ways to achieve this:
-1. Provide the so called **seed-nodes** explicitly on deployment. Essentially
you have a static list of possible seed nodes which are used to build a
cluster. In an ansible based deployment, they are determined for you from the
`hosts` file. On any other deployment model, the
`CONFIG_akka_cluster_seedNodes.$i` variables will need to be provided according
to the [akka cluster
documentation](https://doc.akka.io/docs/akka/2.5/cluster-usage.html#joining-to-seed-nodes).
+1. Provide the so called **seed-nodes** explicitly on deployment. Essentially
you have a static list of possible seed nodes which are used to build a
cluster. In an Ansible based deployment, they are determined for you from the
`hosts` file. On any other deployment model, the
`CONFIG_akka_cluster_seedNodes.$i` variables will need to be provided according
to the [Akka cluster
documentation](https://doc.akka.io/docs/akka/2.5/cluster-usage.html#joining-to-seed-nodes).
2. Discover the nodes from an external service. This is built upon
[akka-management](https://developer.lightbend.com/docs/akka-management/current/)
and by default
[Kubernetes](https://developer.lightbend.com/docs/akka-management/current/discovery.html#discovery-method-kubernetes-api)
and [Mesos
(Marathon)](https://developer.lightbend.com/docs/akka-management/current/discovery.html#discovery-method-marathon-api)
are supported. You can refer to the respective documentation above to configu
[...]
@@ -39,7 +39,7 @@ How to down the members.
1. manually (sending an HTTP or JMX request to the controller). For this case
an external supervisor for the cluster is required, which will down the nodes
and provide an up-to-date list of seed nodes.
2. automatically by setting the "auto-down-property" in controller that will
allow the leader to down the node after a certain timeout. In order to mitigate
brain split one could define a list of seed nodes which are reachable under
static IPs or have static DNS entries.
-Link to akka clustering documentation:
+Link to Akka clustering documentation:
https://doc.akka.io/docs/akka/2.5.4/scala/cluster-usage.html
## Shared state vs. Sharding
diff --git a/docs/mesos.md b/docs/mesos.md
index 4180341..c8cd378 100644
--- a/docs/mesos.md
+++ b/docs/mesos.md
@@ -28,14 +28,14 @@ To enable MesosContainerFactory, use the following TypeSafe
Config properties
| --- | --- | --- | --- |
| `whisk.spi.ContainerFactoryProvider` | required | enable the
MesosContainerFactory |
org.apache.openwhisk.core.mesos.MesosContainerFactoryProvider |
| `whisk.mesos.master-url` | required | Mesos master HTTP endpoint to be
accessed from the invoker for framework subscription |
http://192.168.99.100:5050 |
-| `whisk.mesos.master-url-public` | optional (default to
whisk.mesos.master-url) | public facing Mesos master HTTP endpoint for exposing
logs to cli users | http://192.168.99.100:5050 |
+| `whisk.mesos.master-url-public` | optional (default to
whisk.mesos.master-url) | public facing Mesos master HTTP endpoint for exposing
logs to CLI users | http://192.168.99.100:5050 |
| `whisk.mesos.role` | optional (default *) | Mesos framework role| any string
e.g. `openwhisk` |
| `whisk.mesos.failover-timeout-seconds` | optional (default 0) | how long to
wait for the framework to reconnect with the same id before tasks are
terminated | see
http://mesos.apache.org/documentation/latest/high-availability-framework-guide/
|
-| `whisk.mesos.mesos-link-log-message` | optional (default true) | display a
log message with a link to Mesos when using the default LogStore (or no log
message) | Since logs are not available for invoker to collect from Mesos in
general, you can either use an alternate LogStore or direct users to the Mesos
ui | |
+| `whisk.mesos.mesos-link-log-message` | optional (default true) | display a
log message with a link to Mesos when using the default LogStore (or no log
message) | Since logs are not available for invoker to collect from Mesos in
general, you can either use an alternate LogStore or direct users to the Mesos
UI | |
| `whisk.mesos.constraints` | optional (default []) | placement constraint
strings to use for managed containers | `["att1 LIKE v1", "att2 UNLIKE v2"]` |
|
| `whisk.mesos.blackbox-constraints` | optional (default []) | placement
constraint strings to use for blackbox containers | `["att1 LIKE v1", "att2
UNLIKE v2"]` | |
| `whisk.mesos.constraint-delimiter` | optional (default " ") | delimiter used
to parse constraints | | |
-| `whisk.mesos.teardown-on-exit` | optional (default true) | set to true to
disable the mesos framework on system exit; set for false for HA deployments |
| |
+| `whisk.mesos.teardown-on-exit` | optional (default true) | set to true to
disable the Mesos framework on system exit; set for false for HA deployments |
| |
To set these properties for your invoker, set the corresponding environment
variables e.g.,
```properties
@@ -47,7 +47,7 @@ CONFIG_whisk_mesos_masterUrl=http://192.168.99.100:5050
* Logs are not collected from action containers.
- For now, the Mesos public URL will be included in the logs retrieved via the
wsk CLI. Once log retrieval from external sources is enabled, logs from mesos
containers would have to be routed to the external source, and then retrieved
from that source.
+ For now, the Mesos public URL will be included in the logs retrieved via the
wsk CLI. Once log retrieval from external sources is enabled, logs from Mesos
containers would have to be routed to the external source, and then retrieved
from that source.
* No HA or failover support (single invoker per cluster).
@@ -58,6 +58,6 @@ CONFIG_whisk_mesos_masterUrl=http://192.168.99.100:5050
* the Mesos framework actor is available from the other invoker nodes
* if the node that contains the Mesos framework actor fails:
* the actor will be recreated on a separate invoker node
- * the actor will resubscribe to mesos scheduler API with the same ID
+ * the actor will resubscribe to Mesos scheduler API with the same ID
* the tasks that were previously launched by the actor will be reconciled
* normal operation resumes
diff --git a/docs/metrics.md b/docs/metrics.md
index 4bf3520..217fd37 100644
--- a/docs/metrics.md
+++ b/docs/metrics.md
@@ -223,7 +223,7 @@ Following metrics capture stats around various docker
command executions.
Metrics below are emitted per kafka topic.
-* `openwhisk.histogram.kafka_<topic name>.delay_start` - Time delay between
when a message was pushed to kafka and when it is read within a consumer. This
metric is recorded for every message read.
+* `openwhisk.histogram.kafka_<topic name>.delay_start` - Time delay between
when a message was pushed to Kafka and when it is read within a consumer. This
metric is recorded for every message read.
* `openwhisk.histogram.kafka_<topic name>_count` - Records the Queue size of
the topic. By default this metric is emitted every 60 secs.
Metrics per topic
diff --git a/docs/mobile_sdk.md b/docs/mobile_sdk.md
index 1be708f..b7cde15 100644
--- a/docs/mobile_sdk.md
+++ b/docs/mobile_sdk.md
@@ -220,7 +220,7 @@ whisk.urlSession = session
All actions and triggers have a fully qualified name that is made up of a
namespace, a package, and an action or trigger name. The SDK can accept these
elements as parameters when you are invoking an action or firing a trigger. The
SDK also provides a function that accepts a fully qualified name that looks
like `/mynamespace/mypackage/nameOfActionOrTrigger`. The qualified name string
supports unnamed default values for namespaces and packages that all OpenWhisk
users have, so the followi [...]
-- qName = "foo" results in namespace = default, package = default,
action/trrigger = "foo"
+- qName = "foo" results in namespace = default, package = default,
action/trigger = "foo"
- qName = "mypackage/foo" results in namespace = default, package = mypackage,
action/trigger = "foo"
- qName = "/mynamespace/foo" results in namespace = mynamespace, package =
default, action/trigger = "foo"
- qName = "/mynamespace/mypackage/foo results in namespace = mynamespace,
package = mypackage, action/trigger = "foo"
diff --git a/docs/parameters.md b/docs/parameters.md
index 19945b4..1124d37 100644
--- a/docs/parameters.md
+++ b/docs/parameters.md
@@ -21,7 +21,7 @@
When working with serverless actions, data is supplied by adding parameters to
the actions; these are in the parameter declared as an argument to the main
serverless function. All data arrives this way and the values can be set in a
few different ways. The first option is to supply parameters when an action or
package is created (or updated). This approach is useful for data that stays
the same on every execution, equivalent to environment variables on other
platforms, or for default val [...]
-This page outlines how to configure parameters when deploying packages and
actions, and how to supply parameters when invoking an action. There is also
information on how to use a file to store the parameters and pass the filename,
rather than supplying each parameter individually on the comandline.
+This page outlines how to configure parameters when deploying packages and
actions, and how to supply parameters when invoking an action. There is also
information on how to use a file to store the parameters and pass the filename,
rather than supplying each parameter individually on the command-line.
### Passing parameters to an action at invoke time
diff --git a/docs/reference.md b/docs/reference.md
index c1a3adb..8a928fa 100644
--- a/docs/reference.md
+++ b/docs/reference.md
@@ -70,7 +70,7 @@ More precisely, a name must match the following regular
expression (expressed wi
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](../ansible/README.md#changing-limits).
+As an operator or developer you can change some of the limits using [Ansible
inventory variables](../ansible/README.md#changing-limits).
The following table lists the default limits for actions.
@@ -81,7 +81,7 @@ The following table lists the default limits for actions.
| 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 actioncode | configurable, limit per
action | MB | 48 |
+| 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 |
diff --git a/docs/spi.md b/docs/spi.md
index 831a0d1..368eb51 100644
--- a/docs/spi.md
+++ b/docs/spi.md
@@ -20,7 +20,7 @@
# SPI extensions in OpenWhisk
Alternate implementations of various components follow an SPI (Service
Provider Interface) pattern:
-* The pluggable component is defined as an Spi trait:
+* The pluggable component is defined as an SPI trait:
```scala
import org.apache.openwhisk.spi.Spi
trait ThisIsPluggable extends Spi { ... }
@@ -31,19 +31,19 @@ class TheImpl extends ThisIsPluggable { ... }
class TheOtherImpl extends ThisIsPluggable { ... }
```
-Runtime resolution of an Spi trait to a specific implementation is provided by:
-* `SpiLoader` - a utility for loading the implementation of a specific Spi,
using a resolver to determine the implentations factory classname, and
reflection to load the factory object.
-* `application.conf` - each `Spi` is resolved to a classname based on the
config key provided to `SpiLoader`.
+Runtime resolution of an SPI trait to a specific implementation is provided by:
+* `SpiLoader` - a utility for loading the implementation of a specific SPI,
using a resolver to determine the implementations factory classname, and
reflection to load the factory object.
+* `application.conf` - each `SPI` is resolved to a classname based on the
config key provided to `SpiLoader`.
-Only a single implementation per Spi is usable at runtime, since the key will
have a single string value.
+Only a single implementation per SPI is usable at runtime, since the key will
have a single string value.
# Example
The process to create and use an SPI is as follows:
-## Define the Spi and implementations
+## Define the SPI and implementations
-* Create your Spi trait `YourSpi` as a trait that is an extension of
`whisk.spi.Spi`.
+* Create your SPI trait `YourSpi` as a trait that is an extension of
`whisk.spi.Spi`.
* Create your factory object which extends `YourSpi` and provides the relevant
functionality.
* Create your functionality classes with whatever name you like. The factory
object is supposed to build and return those instances.
@@ -83,7 +83,7 @@ Since SPI implementations are loaded from the classpath, and
a specific implemen
## Including the implementation
-Base openwhisk docker images provide 2 extension points in the classpath for
including the implementation.
+Base OpenWhisk docker images provide 2 extension points in the classpath for
including the implementation.
### Application Jars
diff --git a/tests/performance/README.md b/tests/performance/README.md
index 5c9dbdf..202ef2e 100644
--- a/tests/performance/README.md
+++ b/tests/performance/README.md
@@ -127,7 +127,7 @@ OPENWHISK_HOST="openwhisk.mydomain.com"
MEAN_RESPONSE_TIME="20" API_KEY="UUID:KE
This simulation executes the same action with the same user over and over
again.
The aim of this test is, to test the throughput of the system, if all
containers are always warm.
-The action that is invoked, writes one log line and returns a little json.
+The action that is invoked, writes one log line and returns a little JSON.
The simulations creates the action in the beginning, invokes it as often as
possible for 5 seconds, to warm all containers up and invokes it afterwards for
the given amount of time.
The warmup-phase will not be part of the assertions.
@@ -155,7 +155,7 @@ OPENWHISK_HOST="openwhisk.mydomain.com" CONNECTIONS="10"
REQUESTS_PER_SEC="50" A
##### ColdBlockingInvokeSimulation
-This simulation makes as much cold invocations as possible. Therefor you have
to specify, how many users should be used.
+This simulation makes as much cold invocations as possible. Therefore, you
have to specify how many users should be used.
This amount of users is executing actions in parallel. I recommend using the
same amount of users like your amount of node-js action slots in your invokers.
The users, that are used are loaded from the file
`gatling_tests/src/gatling/resources/data/users.csv`. If you want to increase
the number of parallel users, you have to specify at least this amount of valid
users in that file.
@@ -164,7 +164,7 @@ Each user creates n actions (default is 5). Afterwards all
users are executing t
The aim of the test is, to test the throughput of the system, if all
containers are always cold.
-The action that is invoked, writes one log line and returns a little json.
+The action that is invoked, writes one log line and returns a little JSON.
The test is doing as many requests as possible for the given amount of time
(`SECONDS`). Afterwards it compares if the test reached the intended throughput
(`REQUESTS_PER_SEC`, `MIN_REQUESTS_PER_SEC`).
diff --git a/tools/admin/README-NEXT.md b/tools/admin/README-NEXT.md
index 1c971e0..bcec0b2 100644
--- a/tools/admin/README-NEXT.md
+++ b/tools/admin/README-NEXT.md
@@ -22,7 +22,7 @@
The `wskadmin-next` utility is handy for performing various administrative
operations against an OpenWhisk deployment.
It allows you to create a new subject, manage their namespaces, to block a
subject or delete their record entirely.
-This is a scala based implementation of `wskadmin` utility and is meant to be
DB agnostic.
+This is a Scala based implementation of `wskadmin` utility and is meant to be
DB agnostic.
### Build
@@ -35,7 +35,7 @@ This creates a jar at
`tools/admin/build/libs/openwhisk-admin-tools-1.0.0-SNAPSH
### Setup
-Build task creates an executable at `bin/wskadmin-next`. By default, the
config related to `ArtifactStore` for accessing database will read the
`$OPENWHISK_HOME/whisk.conf`, which was generated by ansible `properties`
deployment. Alternatively, the required config can be also passed by an
overwritten config file. For example to access user details from default
CouchDB setup create a file `application-cli.conf`.
+Build task creates an executable at `bin/wskadmin-next`. By default, the
config related to `ArtifactStore` for accessing database will read the
`$OPENWHISK_HOME/whisk.conf`, which was generated by Ansible `properties`
deployment. Alternatively, the required config can be also passed by an
overwritten config file. For example to access user details from default
CouchDB setup create a file `application-cli.conf`.
include classpath("application.conf")
diff --git a/tools/build/README.md b/tools/build/README.md
index 77d77dd..ae7ac6b 100644
--- a/tools/build/README.md
+++ b/tools/build/README.md
@@ -63,7 +63,7 @@ To change the Travis (or Jenkins) host URL, use `-u`.
- monitor a Travis CI build with job number `N`: `citool monitor N`
- monitor same job `N` until completion: `citool monitor -p N`
- save job output to a file: `citool -o monitor N`
-- for Travis CI matrix builds, use the matrix index after the job number as in
`citool monitor N.i` where 1 <= i <= matrix buidls.
+- for Travis CI matrix builds, use the matrix index after the job number as in
`citool monitor N.i` where 1 <= i <= matrix builds.
To monitor a Jenkins build `B` with job number `N` on host
`https://jenkins.host:port`:
```
@@ -94,8 +94,8 @@ citool -i -b B cat -s -g "tid_124" whisk/logs N
## Gradle Build Scan Integration
-OpenWhisk builds on CI setups have [Gradle Build
Scan](https://gradle.com/build-scans) integrated. Each build on travis pushes
scan reports to
-[Gradle Scan Community Hosted Server](https://scans.gradle.com). To see the
scan report you need to check the travis build logs for lines like
+OpenWhisk builds on CI setups have [Gradle Build
Scan](https://gradle.com/build-scans) integrated. Each build on Travis pushes
scan reports to
+[Gradle Scan Community Hosted Server](https://scans.gradle.com). To see the
scan report you need to check the Travis build logs for lines like
below
```
diff --git a/tools/db/README.md b/tools/db/README.md
index 8b6fe36..128b044 100644
--- a/tools/db/README.md
+++ b/tools/db/README.md
@@ -36,7 +36,7 @@ To try out OpenWhisk without managing your own CouchDB
installation, you can sta
* you will need to run `ansible-playbook couchdb.yml` every time you `clean`
or `teardown` the system (see below)
* you will need to initialize the data store each time (`ansible-playbook
initdb.yml`, see below)
-Detailed instructions are found in the [ansible
readme](../../ansible/README.md).
+Detailed instructions are found in the [Ansible
README](../../ansible/README.md).
## Using Cloudant
diff --git a/tools/dev/README.md b/tools/dev/README.md
index ffd3849..4c6d055 100644
--- a/tools/dev/README.md
+++ b/tools/dev/README.md
@@ -154,14 +154,14 @@ incubator-openwhisk-apigateway
incubator-openwhisk-catalog
...
Stored the list in /openwhisk_home/build/repos/repos.txt
-Stored the json details in /openwhisk_home/build/repos/repos.json
+Stored the JSON details in /openwhisk_home/build/repos/repos.json
```
It generates 2 files
* `repos.txt` - List repository names one per line.
-* `repos.json` - Stores an array of repository details json containing various
repository related details.
+* `repos.json` - Stores an array of repository details JSON containing various
repository related details.
## OpenWhisk Module Status Generator
diff --git a/tools/macos/README.md b/tools/macos/README.md
index 1bc997e..74c1653 100644
--- a/tools/macos/README.md
+++ b/tools/macos/README.md
@@ -81,7 +81,7 @@ No matter which JDK is used, make sure you correctly
configure the environment v
cd /your/path/to/openwhisk
./gradlew distDocker
```
-**Tip** Using `gradlew` handles the installation of the correct version of
gradle to use.
+**Tip** Using `gradlew` handles the installation of the correct version of
Gradle to use.
# Deploy
Follow instructions in [ansible/README.md](../../ansible/README.md)
diff --git a/tools/macos/docker-machine/README.md
b/tools/macos/docker-machine/README.md
index dc5acf0..3e60ca6 100644
--- a/tools/macos/docker-machine/README.md
+++ b/tools/macos/docker-machine/README.md
@@ -126,7 +126,7 @@ cd /your/path/to/openwhisk
cd /your/path/to/openwhisk
./gradlew distDocker
```
-**Tip** Using `gradlew` handles the installation of the correct version of
gradle to use.
+**Tip** Using `gradlew` handles the installation of the correct version of
Gradle to use.
# Deploy
diff --git a/tools/ubuntu-setup/README.md b/tools/ubuntu-setup/README.md
index 9446751..db2d5f6 100644
--- a/tools/ubuntu-setup/README.md
+++ b/tools/ubuntu-setup/README.md
@@ -65,7 +65,7 @@ Follow instructions [tools/db/README.md](../db/README.md) on
how to configure a
Follow the instructions in [ansible/README.md](../../ansible/README.md) to
deploy and teardown OpenWhisk within a single machine or VM.
Once deployed, several Docker containers will be running in your machine.
-You can check that containers are running by using the docker cli with the
command `docker ps`.
+You can check that containers are running by using the docker CLI with the
command `docker ps`.
### Configure the CLI
Follow instructions in [Configure CLI](../../docs/cli.md). The API host
diff --git a/tools/vagrant/README.md b/tools/vagrant/README.md
index 0697c4b..a59e6e2 100644
--- a/tools/vagrant/README.md
+++ b/tools/vagrant/README.md
@@ -71,7 +71,7 @@ export OW_DB_PORT=5984 ./hello
**Note:**
Data will persist after [safe re-deploy](#safe-re-deploy-after-vm-restart),
but will be destroyed if you
-initialze the DB. For more information on data store configurations see
+initialize the DB. For more information on data store configurations see
[tools/db/README.md](../db/README.md).
@@ -177,7 +177,7 @@ cd ${OPENWHISK_HOME}
```
## Building OpenWhisk
-Use gradle to build docker images from inside the VM, this is done
automatically
+Use Gradle to build docker images from inside the VM, this is done
automatically
once at VM creation.
```
@@ -207,9 +207,9 @@ Then update line with the curl download command like
```
RUN curl -sSL -o docker-${DOCKER_VERSION}.tgz
https://download.docker.com/linux/static/stable/x86_64/docker-${DOCKER_VERSION}.tgz
&& \
```
-Notice that the hostname where to download the cli is different for newer
versions.
+Notice that the hostname where to download the CLI is different for newer
versions.
-Then update the ansible configuration to enable the use of runc, edit
[](../../ansible/environments/vagrant/group_vars/all)
+Then update the Ansible configuration to enable the use of runc, edit
[](../../ansible/environments/vagrant/group_vars/all)
```
invoker_use_runc: true
```
