This is an automated email from the ASF dual-hosted git repository.
csantanapr pushed a commit to branch master
in repository
https://gitbox.apache.org/repos/asf/incubator-openwhisk-deploy-kube.git
The following commit(s) were added to refs/heads/master by this push:
new 5d1b404 Small improvements to README (#358)
5d1b404 is described below
commit 5d1b4044aac51d4c376b0d992c1f7229fb6d05c2
Author: David Grove <[email protected]>
AuthorDate: Fri Nov 16 14:56:24 2018 -0500
Small improvements to README (#358)
---
README.md | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/README.md b/README.md
index 4bd0d7f..697e487 100644
--- a/README.md
+++ b/README.md
@@ -138,8 +138,11 @@ tell the `wsk` CLI how to connect to your OpenWhisk
deployment.
## Initial setup
Indicate the Kubernetes worker nodes that should be used to execute
-user containers. Do this by labeling each node with
-`openwhisk-role=invoker`. For a single node cluster, simply do
+user containers by OpenWhisk's invokers. Do this by labeling each node with
+`openwhisk-role=invoker`. In its default configuration,
+OpenWhisk assumes it has exclusive use of these invoker nodes and
+will schedule work on them directly, completely bypassing the Kubernetes
+scheduler. For a single node cluster, simply do
```shell
kubectl label nodes --all openwhisk-role=invoker
```
@@ -149,14 +152,15 @@ you want to be an invoker, execute
$ kubectl label nodes <INVOKER_NODE_NAME> openwhisk-role=invoker
```
-For optimal scheduling of pods on a multi-node cluster, you can
-optionally also label non-invoker nodes to fine-tune Kubernetes's
-scheduling decisions. You can label with `openwhisk-role=core`
-to indicate nodes which should run the OpenWhisk control plan
+For more precise control of the placement of the rest of OpenWhisk's
+pods on a multi-node cluster, you can optionally label additional
+non-invoker worker nodes. Use the label `openwhisk-role=core`
+to indicate nodes which should run the OpenWhisk control plane
(the controller, kafka, zookeeeper, and couchdb pods).
-If you have a dedicated Ingress node, optionally label it with
+If you have dedicated Ingress nodes, label them with
`openwhisk-role=edge`. Finally, if you want to run the OpenWhisk
-Event Providers on specific nodes, label them with `openwhisk-role=provider`.
+Event Providers on specific nodes, label those nodes with
+`openwhisk-role=provider`.
## Customize the Deployment
@@ -192,9 +196,8 @@ Helm auto-generate one for you.
You can use the command `helm status owdev` to get a summary
of the various Kubernetes artifacts that make up your OpenWhisk
-deployment. Once all the pods shown by the status command are in
-either the `Running` or `Completed` state, your OpenWhisk deployment
-is ready to be used.
+deployment. Once the `install-packages` Pod is in the `Completed` state,
+your OpenWhisk deployment is ready to be used.
## Configure the wsk CLI
