* IAM User Cloudformation Enhancements: update, delete, getatt.
* AWS::IAM::Policy Support
* Added unit tests for AWS:IAM:Policy for roles and groups. Fixed bug related to groups.
* AWS:IAM:AccessKey CloudFormation support.
* Refactor of CloudFormation parsing.py methods to simplify and standardize how they call to the models. Adjusted some models accordingly.
* Further model CloudFormation support changes to align with revised CloudFormation logic. Mostly avoidance of getting resoure name from properties.
* Support for Kinesis Stream RetentionPeriodHours param.
* Kinesis Stream Cloudformation Tag Support.
* Added omitted 'region' param to boto3.client() calls in new tests.
Co-authored-by: Joseph Weitekamp <jweite@amazon.com>
* fix sqs tag list from cloudformation resource creation
the method `create_from_cloudformation_json` of the Sqs resource
does not handle the difference of format of the Tags field in the
resource template and the format expected in Sqs resource class.
In cfn resource template Tags is specified as a list of dicts. But
the Sqs resource expects that the tags field be a single dict.
This behaviour causes a crash when a queue is created with tags
from `create_from_cloudformation_json` and later the list_queue_tags
is called because it tries to call `items` from `queue.tags` but
tags is actually a list of dicts.
* fix comment
* fix linter
* minor
Co-authored-by: Hudo Assenco <hudo.assenco@gmail.com>
* Fix : SQS - Added support for attribute labels for send_message function
* Add integration test on receive message function
* Add send message invalid datetype integration test and fix SQS MessageAttributesInvalid exceptions
For our local development setup we have found that moto is using around 25% CPU constantly. Digging in with gdb it turned out that it was burning that CPU in the sleeping loop. Here i'm increasing the sleep by 10x which brings the idle CPU usage down by 10x (to ~2%).
I'm not familiar enough with the moto/sqs codebase to know if lengthening this sleep will have an adverse effect; however, in other Python dev I've noticed that (in Python 2.7 anyway..) Python threading won't context switch a thread until a sleep of at least 0.01 seconds is performed (shockingly long!). So based on this guesswork I suspect sleeping for 0.01 seconds won't cause any grief.
When a queue is created with the ReceiveMessageWaitTimeSeconds
attribute the value is never converted to an integer. When the
ReceiveMessage action is called it tries to compare the string
ReceiveMessageWaitTimeSeconds with the min and max wait times which
raises a TypeError.
The solution is to convert this value to an integer before comparing.
