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
It's a curious issue that if you need to store variables for a module in a dict then when you pass them over to the module they will always be a string. (See example below.)
There doesn't seem to be any sane way to pass a true integer to the module in this case. Which leaves the only way around this as having the module itself ensure the values passed are cast as integers before they are sent to the AWS API. Given we know the API is fussy and we haven't seen anything like this with other modules, I'm assuming the "usual" behaviour for these AWS modules is to cast integers as there's no way to guarantee Ansible/jinja will send a true integer to the module. This module should do this too.
We've patched this module locally and it now works for us, I'll provide a PR tomorrow with our working changes. PR provided! #716
$ pip3 show boto boto3 botocoreName: botoVersion: 2.44.0Summary: Amazon Web Services LibraryHome-page: https://github.com/boto/boto/Author: Mitch GarnaatAuthor-email: [email protected]License: MITLocation: /usr/lib/python3/dist-packagesRequires: Required-by: ---Name: boto3Version: 1.17.98Summary: The AWS SDK for PythonHome-page: https://github.com/boto/boto3Author: Amazon Web ServicesAuthor-email: NoneLicense: Apache License 2.0Location: /usr/local/lib/python3.7/dist-packagesRequires: jmespath, botocore, s3transferRequired-by: ---Name: botocoreVersion: 1.21.40Summary: Low-level, data-driven core of boto 3.Home-page: https://github.com/boto/botocoreAuthor: Amazon Web ServicesAuthor-email: NoneLicense: Apache License 2.0Location: /usr/local/lib/python3.7/dist-packagesRequires: python-dateutil, jmespath, urllib3Required-by: s3transfer, boto3, awscli
Configuration
$ ansible-config dump --only-changed
OS / Environment
Debian Buster
Steps to Reproduce
If my playbook looks like this - note particularly the vars, the SNS vars nested neatly into a dict for readability:
---
- hosts: localhosttasks:
- include: sns.ymlvars:
aws_sns:
name: "alarms"# Name of the alarm.display_name: ""# Display name for the topic, for when the topic is owned by this AWS account.delivery_policy_default_healthy_retry_policy_min_delay_target: 20delivery_policy_default_healthy_retry_policy_max_delay_target: 20delivery_policy_default_healthy_retry_policy_num_retries: 3delivery_policy_default_healthy_retry_policy_backoff_function: "linear"delivery_policy_disable_subscription_overrides: falsesubscriptions:
- endpoint: "[email protected]"protocol: "email"
There's nothing wrong with that, we're even casting it as an int with jinja to try and be doubly sure, but it will still fail with this:
"msg": "Couldn't set topic delivery policy: An error occurred (InvalidParameter) when calling the SetTopicAttributes operation: Invalid parameter: DeliveryPolicy: http.defaultHealthyRetryPolicy.minDelayTarget type mismatch, expecting integer, received a string"
Expected Results
I expect the integers passed in the aws_sns dict to be respected as integers and passed as integers to the AWS API.
Actual Results
"msg": "Couldn't set topic delivery policy: An error occurred (InvalidParameter) when calling the SetTopicAttributes operation: Invalid parameter: DeliveryPolicy: http.defaultHealthyRetryPolicy.minDelayTarget type mismatch, expecting integer, received a string"
Code of Conduct
I agree to follow the Ansible Code of Conduct
The text was updated successfully, but these errors were encountered:
Summary
It's a curious issue that if you need to store variables for a module in a dict then when you pass them over to the module they will always be a string. (See example below.)
There doesn't seem to be any sane way to pass a true integer to the module in this case. Which leaves the only way around this as having the module itself ensure the values passed are cast as integers before they are sent to the AWS API. Given we know the API is fussy and we haven't seen anything like this with other modules, I'm assuming the "usual" behaviour for these AWS modules is to cast integers as there's no way to guarantee Ansible/jinja will send a true integer to the module. This module should do this too.
We've patched this module locally and it now works for us, I'll provide a PR tomorrow with our working changes.PR provided! #716Issue Type
Bug Report
Component Name
sns_topic
Ansible Version
Collection Versions
AWS SDK versions
Configuration
$ ansible-config dump --only-changed
OS / Environment
Debian Buster
Steps to Reproduce
If my playbook looks like this - note particularly the vars, the SNS vars nested neatly into a dict for readability:
And my role task looks like this in
sns.yml
:There's nothing wrong with that, we're even casting it as an int with jinja to try and be doubly sure, but it will still fail with this:
"msg": "Couldn't set topic delivery policy: An error occurred (InvalidParameter) when calling the SetTopicAttributes operation: Invalid parameter: DeliveryPolicy: http.defaultHealthyRetryPolicy.minDelayTarget type mismatch, expecting integer, received a string"
Expected Results
I expect the integers passed in the
aws_sns
dict to be respected as integers and passed as integers to the AWS API.Actual Results
"msg": "Couldn't set topic delivery policy: An error occurred (InvalidParameter) when calling the SetTopicAttributes operation: Invalid parameter: DeliveryPolicy: http.defaultHealthyRetryPolicy.minDelayTarget type mismatch, expecting integer, received a string"
Code of Conduct
The text was updated successfully, but these errors were encountered: