Moto imports a class in boto that did not exist before boto 2.33.0
Partial traceback showing ImportError with versions of boto < 2.33.0:
File "/src/python/moto/moto/__init__.py", line 8, in <module>
from .autoscaling import mock_autoscaling # flake8: noqa
File "/src/python/moto/moto/autoscaling/__init__.py", line 2, in <module>
from .models import autoscaling_backends
File "/src/python/moto/moto/autoscaling/models.py", line 5, in <module>
from moto.elb import elb_backends
File "/src/python/moto/moto/elb/__init__.py", line 2, in <module>
from .models import elb_backends
File "/src/python/moto/moto/elb/models.py", line 4, in <module>
from boto.ec2.elb.attributes import (
ImportError: cannot import name ConnectionSettingAttribute
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>
