* 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>
Without the added `return {}`, calling route53.list_tags_for_resource
when called with a ResourceId of a resource without any tags would
result in the error:
jinja2.exceptions.UndefinedError: 'None' has no attribute 'items'
Because the LIST_TAGS_FOR_RESOURCE_RESPONSE was given None instead of
empty dict.
This now allows list_tags_for_resource to be called without issue on
tag-less resources.
According to the documentation [1], name should be filtered first,
followed by type.
> If you specify both Name and Type
> The results begin with the first resource record set in the list
> whose name is greater than or equal to Name, and whose type is
> greater than or equal to Type.
[1]: https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html
Previously this was not checked so an existing record (e.g. with type A) would be overwritten on upsert by a record with the same name but different type (e.g. TXT).
This commit also:
* publicizes the type variable appending the underscore affix (required to maintain compatibility with CloudFormation which sets type as the CF type),
* fixes a wrong assumption in tests that UPSERT applies a change to Type (it creates a distinct record instead),
* Updates ACM model to use serial_number instead of deprecated and remove serial causing Travis failures.
AWS Route53 treats www.example.com (without a trailing dot)
and www.example.com. (with a trailing dot) as identical.
Hence, after creating a `www.example.com` record,
`www.example.com.` name is saved in Route53.
But moto treated `www.example.com` and `www.example.com.` as different.
This commit fixes the moto behavior.
According to AWS API reference and Boto documentation they are to begin the record listing from,
not for filtering. So their current behavior in moto is not consistent with AWS.
We will continue to store just the unique ID, but since the AWS API
returns /hostedzone/<id>, we should accept attempts to pass that back.
For example, both just the ID as well as /hostedzone/<id> work for
specifying the HostedZoneId of a ResourceRecordSet in CloudFormation. So
we should support that too.
Signed-off-by: Scott Greene <scott.greene@getbraintree.com>
While there isn't an API method exposed for directly deleting a Route 53
RecordSet (it's performed via POST that acts more like a PATCH than
anything
else)[http://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html],
CloudFormation can have templates which contain RecordSets which refer
to zones that don't exist inside the template. Ergo, we need a way to
effect a delete upon these RecordSets when we don't have a direct
reference to the zone.
This exposes a delete method that isn't hooked up to any response (and
rightfully so), it just enables the ~polymorphic deletion behavior that
we've written into the CloudFormation implementation.
Signed-off-by: Scott Greene <scott.greene@getbraintree.com>
