According to
http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/allocation-tag-restrictions.html
"Reserved prefix—aws:
AWS-assigned tag names and values are automatically assigned the aws:
prefix, which the user cannot assign. AWS-assigned tag names do not
count towards the tag limit of 10. User-assigned tag names have the
prefix user: in the Cost Allocation Report."
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>
Only implemented for ASGs and LCs since they're all we cared about for
our particular problem. It should be easy to follow this pattern for
other resource types, though.
Signed-off-by: Scott Greene <scott.greene@getbraintree.com>
I'm not certain that this is the approach that's desired. It'd be nice
to dynamically convert the keys one way or the other. Looking for
feedback.
Signed-off-by: Scott Greene <scott.greene@getbraintree.com>
botocore 1.3.29 (new as of yesterday) breaks a few of the s3 and
lambda tests; something about a StringIO being closed prematurely.
¯\_(ツ)_/¯
boto3 doesn't pin the botocore version; as a result the new version of
botocore gets pulled in transitively, breaking today's builds.
Signed-off-by: Scott Greene <scott.greene@getbraintree.com>
botocore 1.3.29 (new as of yesterday) breaks a few of the s3 and
lambda tests; something about a StringIO being closed prematurely.
¯\_(ツ)_/¯
boto3 doesn't pin the botocore version; as a result the new version of
botocore gets pulled in transitively, breaking today's builds.
Signed-off-by: Scott Greene <scott.greene@getbraintree.com>
