You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Sumo Logic provider appears to not utilize any sort of retry logic when creating a sumologic_kinesis_log_source, or at least none that appropriately handles the eventual consistency issue with IAM Role Authentication. Given the following HCL:
We will consistently receive this error on initial creation:
│ Error: {
│ "status" : 400,
│ "id" : "IVE-REPLACED-THISID",
│ "code" : "collectors.validation.fields.invalid",
│ "message" : "The S3 bucket 'bucketName=bucket-name-replaced-here-but-the-bucket-definitely-exists' is not readable. The following permission is missing : 'missingPermission=ListBucketVersions'."
│ }
│
│ with module.us-west-2.module.common.module.api.module.modulenamegoeshere.sumologic_kinesis_log_source.cwl-shipper,
│ on .terraform/modules/us-west-2.common.api.modulenamegoeshere/sumologic-collector.tf line 1, in resource "sumologic_kinesis_log_source" "cwl-shipper":
│ 1: resource "sumologic_kinesis_log_source" "cwl-shipper" {
Now, we know the error is not a permissions error because on the very next apply with zero changes, the apply succeeds with no errors. So, that means the issue is the eventual consistency that's warned about in the docs:
Now that you have completed these steps and have created an IAM Role you need to wait two to five minutes before using it for an AWS Source's authentication. This is to account for AWS's eventual consistency.
This seems like a perfect usecase for backoff/retry logic.
The text was updated successfully, but these errors were encountered:
The Sumo Logic provider appears to not utilize any sort of retry logic when creating a sumologic_kinesis_log_source, or at least none that appropriately handles the eventual consistency issue with IAM Role Authentication. Given the following HCL:
We will consistently receive this error on initial creation:
Now, we know the error is not a permissions error because on the very next apply with zero changes, the apply succeeds with no errors. So, that means the issue is the eventual consistency that's warned about in the docs:
This seems like a perfect usecase for backoff/retry logic.
The text was updated successfully, but these errors were encountered: