You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openwhisk.apache.org by GitBox <gi...@apache.org> on 2018/11/16 19:56:25 UTC

[GitHub] csantanapr closed pull request #358: Small improvements to README

csantanapr closed pull request #358: Small improvements to README
URL: https://github.com/apache/incubator-openwhisk-deploy-kube/pull/358
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

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
 


 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services