[openwhisk-deploy-kube] branch master updated: fix typo in scaling docs (#677)

[ra...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

rabbah pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/openwhisk-deploy-kube.git


The following commit(s) were added to refs/heads/master by this push:
     new baeef18  fix typo in scaling docs (#677)
baeef18 is described below

commit baeef18c4f1bb277e5ea92819141191ebca80a76
Author: David Grove <dg...@users.noreply.github.com>
AuthorDate: Fri Mar 5 09:31:03 2021 -0500

    fix typo in scaling docs (#677)
---
 README.md                                | 2 +-
 docs/k8s-custom-build-cluster-scaleup.md | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 3ac083b..1fa5d2f 100644
--- a/README.md
+++ b/README.md
@@ -334,7 +334,7 @@ If your deployment is not working, check our
 
 Using defaults, your deployment is configured to provide a bare-minimum working platform for testing and exploration. For your specialized workloads, you can scale-up your openwhisk deployment by defining your deployment configurations in your `mycluster.yaml` which overrides the defaults in `helm/openwhisk/values.yaml`. Some important parameters to consider (for other parameters, check `helm/openwhisk/values.yaml` and [configurationChoices](./docs/configurationChoices.md)):
 * `actionsInvokesPerminute`: limits the maximum number of invocations per minute.
-* `actionsInvokesPerminute`: limits the maximum concurrent invocations.
+* `actionsInvokesConcurrent`: limits the maximum concurrent invocations.
 * `containerPool`: total memory available per `invoker` instance. `Invoker` uses this memory to create containers for user-actions. The concurrency-limit (actions running in parallel) will depend upon the total memory configured for `containerPool` and memory allocated per action (`default:` 256mb per container).
 
 For more information about increasing concurrency-limit, check [scaling-up your deployment](./docs/k8s-custom-build-cluster-scaleup.md).
diff --git a/docs/k8s-custom-build-cluster-scaleup.md b/docs/k8s-custom-build-cluster-scaleup.md
index e290371..3632794 100644
--- a/docs/k8s-custom-build-cluster-scaleup.md
+++ b/docs/k8s-custom-build-cluster-scaleup.md
@@ -29,7 +29,7 @@ The default configurations of openwhisk deployment, support low concurrency-limi
 
 By default, openwhisk deployment is configured to provide a bare-minimum working platform for testing and exploration. For your specialized workloads, you can scale-up your openwhisk deployment by defining your deployment configurations in your `mycluster.yaml` which overrides the defaults in `helm/openwhisk/values.yaml`. Some important parameters to consider (for other parameters, check `helm/openwhisk/values.yaml` and [configurationChoices](./docs/configurationChoices.md)):
 * `actionsInvokesPerminute`: limits the maximum number of invocations per minute.
-* `actionsInvokesPerminute`: limits the maximum concurrent invocations.
+* `actionsInvokesConcurrent`: limits the maximum concurrent invocations.
 * `containerPool.userMemory`: total memory available per `invoker` instance. `Invoker` uses this memory to create containers for user-actions. The concurrency-limit (actions running in parallel) will depend upon the total memory configured for `containerPool` and memory allocated per action (`default:` 256mb per container).
 * `triggersFiresPerminute`: limits the maximum triggers invoked per minute.