Fix vaultUri typo in authentication.md and other minor doc changes (k…

…edacore#1185)

content/blog/2021-05-27-azure-pipelines-scaler.md

@@ -244,5 +244,5 @@ Once that happens, you will see the jobs in the Azure Pipelines' agent pool:
 
 ![scaledjobs agents](/img/blog/azure-pipelines-scaler/jobs-agents-autoscaled.png)
 
-Using a `ScaledJob` is the preferred way to autoscale your Azure Pipelines agents if you have long running jobs.
+Using a `ScaledJob` is the preferred way to autoscale your Azure Pipelines agents if you have long-running jobs.
 The other option is using a `deployment` and leveraging the container lifecycle. ([docs](https://keda.sh/docs/1.4/concepts/scaling-deployments/#leverage-the-container-lifecycle))

content/docs/1.4/concepts/scaling-deployments.md

@@ -16,7 +16,7 @@ For example, if you wanted to use KEDA with an Apache Kafka topic as event sourc
 * When no messages are pending processing, KEDA can scale the deployment to zero.
 * When a message arrives, KEDA detects this event and activates the deployment.
 * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.
-* As more messages arrive on the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.
+* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.
 * Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.
 
 ## ScaledObject spec
@@ -61,7 +61,7 @@ The name of the deployment this scaledObject is for. This is the deployment KEDA
   pollingInterval: 30  # Optional. Default: 30 seconds
 ```
 
-This is the interval to check each trigger on. By default KEDA will check each trigger source on every ScaledObject every 30 seconds.
+This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.
 
 **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the deployment up or down accordingly.
 
@@ -71,7 +71,7 @@ This is the interval to check each trigger on. By default KEDA will check each t
   cooldownPeriod:  300 # Optional. Default: 300 seconds
 ```
 
-The period to wait after the last trigger reported active before scaling the deployment back to 0. By default it's 5 minutes (300 seconds).
+The period to wait after the last trigger reported active before scaling the deployment back to 0. By default, it's 5 minutes (300 seconds).
 
 The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment`, KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-cooldowndelay).
 
@@ -83,7 +83,7 @@ The `cooldownPeriod` only applies after a trigger occurs; when you first create
   minReplicaCount: 0   # Optional. Default: 0
 ```
 
-Minimum number of replicas KEDA will scale the deployment down to. By default it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the deployment to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the deployment it will respect the value set there.
+Minimum number of replicas KEDA will scale the deployment down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the deployment to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the deployment it will respect the value set there.
 
 ---
 
@@ -95,7 +95,7 @@ This setting is passed to the HPA definition that KEDA will create for a given d
 
 ## Long-running executions
 
-One important consideration to make is how this pattern can work with long running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.
+One important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.
 
 There are two main ways to handle this scenario.
 
@@ -109,4 +109,4 @@ Using this method can preserve a replica and enable long-running executions.  Ho
 
 ### Run as jobs
 
-The other alternative to handling long running executions is by running the event driven code in Kubernetes Jobs instead of Deployments.  This approach is discussed [in the next section](../scaling-jobs).
+The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments.  This approach is discussed [in the next section](../scaling-jobs).

content/docs/1.4/concepts/scaling-jobs.md

@@ -6,7 +6,7 @@ weight = 300
 
 ## Overview
 
-As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.
+As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.
 
 For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:
 

content/docs/1.4/scalers/rabbitmq-queue.md

@@ -25,7 +25,7 @@ The `host` value is the name of the environment variable your deployment uses to
 
 `apiHost` has the similar format but for HTTP API endpoint, like `https://guest:password@localhost:443/vhostname`. Note it has optional vhost name after the host slash which will be used to scope API request.
 
-By default `includeUnacked` is `false` in this case scaler uses AMQP protocol, requires `host` and only counts messages in the queue and ignores unacked messages.
+By default, `includeUnacked` is `false` in this case scaler uses AMQP protocol, requires `host` and only counts messages in the queue and ignores unacked messages.
 If `includeUnacked` is `true` then `host` is not required but `apiHost` is required in this case scaler uses HTTP management API and counts messages in the queue + unacked messages count.
 
 ### Authentication Parameters

content/docs/1.5/concepts/scaling-deployments.md

@@ -16,7 +16,7 @@ For example, if you wanted to use KEDA with an Apache Kafka topic as event sourc
 * When no messages are pending processing, KEDA can scale the deployment to zero.
 * When a message arrives, KEDA detects this event and activates the deployment.
 * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.
-* As more messages arrive on the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.
+* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.
 * Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.
 
 ## ScaledObject spec
@@ -61,7 +61,7 @@ The name of the deployment this scaledObject is for. This is the deployment KEDA
   pollingInterval: 30  # Optional. Default: 30 seconds
 ```
 
-This is the interval to check each trigger on. By default KEDA will check each trigger source on every ScaledObject every 30 seconds.
+This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.
 
 **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the deployment up or down accordingly.
 
@@ -71,7 +71,7 @@ This is the interval to check each trigger on. By default KEDA will check each t
   cooldownPeriod:  300 # Optional. Default: 300 seconds
 ```
 
-The period to wait after the last trigger reported active before scaling the deployment back to 0. By default it's 5 minutes (300 seconds).
+The period to wait after the last trigger reported active before scaling the deployment back to 0. By default, it's 5 minutes (300 seconds).
 
 The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment`, KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-cooldowndelay).
 
@@ -84,7 +84,7 @@ The `cooldownPeriod` only applies after a trigger occurs; when you first create
   minReplicaCount: 0   # Optional. Default: 0
 ```
 
-Minimum number of replicas KEDA will scale the deployment down to. By default it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the deployment to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the deployment it will respect the value set there.
+Minimum number of replicas KEDA will scale the deployment down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the deployment to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the deployment it will respect the value set there.
 
 ---
 
@@ -96,7 +96,7 @@ This setting is passed to the HPA definition that KEDA will create for a given d
 
 ## Long-running executions
 
-One important consideration to make is how this pattern can work with long running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.
+One important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.
 
 There are two main ways to handle this scenario.
 
@@ -110,4 +110,4 @@ Using this method can preserve a replica and enable long-running executions.  Ho
 
 ### Run as jobs
 
-The other alternative to handling long running executions is by running the event driven code in Kubernetes Jobs instead of Deployments.  This approach is discussed [in the next section](../scaling-jobs).
+The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments.  This approach is discussed [in the next section](../scaling-jobs).

content/docs/1.5/concepts/scaling-jobs.md

@@ -6,7 +6,7 @@ weight = 300
 
 ## Overview
 
-As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.
+As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.
 
 For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:
 

content/docs/1.5/scalers/rabbitmq-queue.md

@@ -28,7 +28,7 @@ triggers:
 - `host` - Value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.  The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost`.
 - `queueName` - Name of the queue to read message from.
 - `queueLength` - Queue length target for HPA. (Default: `20`, Optional)
-- `includeUnacked` - By default `includeUnacked` is `false` in this case scaler uses AMQP protocol, requires `host` and only counts messages in the queue and ignores unacked messages. If `includeUnacked` is `true` then `host` is not required but `apiHost` is required in this case scaler uses HTTP management API and counts messages in the queue + unacked messages count. `host` or `apiHost` value comes from authentication trigger. (Optional)
+- `includeUnacked` - By default, `includeUnacked` is `false` in this case scaler uses AMQP protocol, requires `host` and only counts messages in the queue and ignores unacked messages. If `includeUnacked` is `true` then `host` is not required but `apiHost` is required in this case scaler uses HTTP management API and counts messages in the queue + unacked messages count. `host` or `apiHost` value comes from authentication trigger. (Optional)
 - `apiHost` - It has similar format as of `host` but for HTTP API endpoint, like https://guest:password@localhost:443/vhostname.
 
 Note `host` and `apiHost` both have an optional vhost name after the host slash which will be used to scope API request.

content/docs/2.0/concepts/scaling-deployments.md

@@ -18,7 +18,7 @@ For example, if you wanted to use KEDA with an Apache Kafka topic as event sourc
 * When no messages are pending processing, KEDA can scale the deployment to zero.
 * When a message arrives, KEDA detects this event and activates the deployment.
 * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.
-* As more messages arrive on the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.
+* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.
 * Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.
 
 ### Scaling of Custom Resources
@@ -87,7 +87,7 @@ To scale Kubernetes Deployments only `name` is needed to be specified, if one wa
   pollingInterval: 30  # Optional. Default: 30 seconds
 ```
 
-This is the interval to check each trigger on. By default KEDA will check each trigger source on every ScaledObject every 30 seconds.
+This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.
 
 **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.
 
@@ -97,7 +97,7 @@ This is the interval to check each trigger on. By default KEDA will check each t
   cooldownPeriod:  300 # Optional. Default: 300 seconds
 ```
 
-The period to wait after the last trigger reported active before scaling the resource back to 0. By default it's 5 minutes (300 seconds).
+The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).
 
 The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-cooldowndelay).
 
@@ -109,7 +109,7 @@ The `cooldownPeriod` only applies after a trigger occurs; when you first create
   minReplicaCount: 0   # Optional. Default: 0
 ```
 
-Minimum number of replicas KEDA will scale the resource down to. By default it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the resource to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the resource it will respect the value set there.
+Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the resource to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the resource it will respect the value set there.
 
 ---
 
@@ -157,7 +157,7 @@ Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be
 
 ## Long-running executions
 
-One important consideration to make is how this pattern can work with long running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.
+One important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.
 
 There are two main ways to handle this scenario.
 
@@ -171,4 +171,4 @@ Using this method can preserve a replica and enable long-running executions.  Ho
 
 ### Run as jobs
 
-The other alternative to handling long running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).
+The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).