* Fix exception with "object has no attribute"
When use this code:
client = boto3.client('lambda')
client.get_policy([...])
moto rise:
```
moto/awslambda/responses.py", line 109, in _get_policy
lambda_backend = self.get_lambda_backend(full_url)
Exception: 'LambdaResponse' object has no attribute 'get_lambda_backend'
```
* fix shadows built-in name
* Added Filtering support for S3 lifecycle
Also added `ExpiredObjectDeleteMarker`.
closes#1533closes#1479
* Result set no longer contains "Prefix" if "Filter" is set.
* Flask Request object does not have a 'body' attribute, changed to 'data'
* Making moto 'glaciar' more aws 'glaciar' like.
* Making moto 'glacier' more aws 'glacier' like.
* Fixing Travis errors?
* OK, check if object has proper attribute because HTTPrettyRequest has no data attribute and Python Requests has no body attribute.
* Output to match test expectation; sleep for 60 seconds to mimic actual wait time.
* Amending test_describe_job to reflect changes.
* Shorten time from 1 minute to seconds.
* Shorten sleep time in test. Forgot about the test.
* Some circumstances need subdomains to be ignored rather that interpreted as bucketname, this patch allows such behaviour to be configured
* Adding helper case whereby localstack features as path based exception
* Remove whitespace :(
* Enable Extended CIDR Associations on VPC
* Ooops missed the utils, try to be more flakey?, remove unnecessary part in tests
* try to be even more flakey
In commit 4157abe8de, the Jinja2
dep in setup.py was changed from being unpinned to requiring version
2.8 or newer. That change was made in response to this issue:
https://github.com/spulec/moto/issues/728
which pointed out that the use of 'lstrip_blocks' needed to
be supported. Support for that option was added in Jinja 2.7,
so it seems like the best option here, unless 2.8 is truly
required by moto, would be to allow Jinja 2.7.3 and newer --
preventing dep resolution conflicts in Python projects that pin
Jinja2 2.7.3 but also need to use moto.
I had an EMR step that contained a `&` and this caused the ListStep call to fail.
I've added the `| escape` filter to handle it in this case and a few other cases that look like they could suffer the same fate.
* Delete the volume used during AMI creation
Creating an AMI doesn't actually result in the creation of an EBS
volume, although the associated snapshot does reference one. To that
end, delete the volume once we've used it.
* Add `owner_id` to `Snapshot`, verify AMI snapshots
The default AMIs which are created by moto have EBS volume mappings
but the snapshots associated with those don't have the correct
owners set.
This adds the owner to the snapshot model and passes it through from
the JSON data.
