Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWS SQS Scaler: Document additions of NotVisible messages in scaling calculations #398

Merged
merged 1 commit into from
Mar 15, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions content/docs/2.2/scalers/aws-sqs.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,15 +26,18 @@ triggers:
**Parameter list:**

- `queueURL` - Full URL for the SQS Queue
- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual `ApproximateNumberOfMessages` in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)
- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)

> For the purposes of scaling, "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVislble`, since `NotVisible` in SQS terms means the message is still in-flight/processing.

- `awsRegion` - AWS Region for the SQS Queue
- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below).

> When `identityOwner` set to `operator` - the only requirement is that the Keda operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.

### Authentication Parameters

> These parameters are relevant only when `identityOwner` is set to `pod`.
> These parameters are relevant only when `identityOwner` is set to `pod`.

You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.

Expand Down Expand Up @@ -63,7 +66,7 @@ metadata:
data:
AWS_ACCESS_KEY_ID: <encoded-user-id>
AWS_SECRET_ACCESS_KEY: <encoded-key>
---
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
Expand Down