Also I found extra tests for describe_task_definition and deregister_task_definition that were not being run,
so I changed their names so they are found by pytest and made them pass. I also added checks to them for the new
status field.
The mocked response for ECS RegisterTaskDefinition has drifted from what
actually returns when run against a real ECS endpoint. I created a
minimal task definition for both EC2:
```
>>> ecs.register_task_definition(
family="moto",
containerDefinitions=[
{
"name": "hello_world",
"image": "hello-world:latest",
"memory": 400
}
]
)["taskDefinition"]
{'taskDefinitionArn': 'arn:aws:ecs:us-east-1:************:task-definition/moto:1',
'containerDefinitions': [{'name': 'hello_world',
'image': 'hello-world:latest',
'cpu': 0,
'memory': 400,
'portMappings': [],
'essential': True,
'environment': [],
'mountPoints': [],
'volumesFrom': []}],
'family': 'moto',
'revision': 1,
'volumes': [],
'status': 'ACTIVE',
'placementConstraints': [],
'compatibilities': ['EC2']}
```
and FARGATE:
```
>>> ecs.register_task_definition(
family="moto",
containerDefinitions=[
{
"name": "hello_world",
"image": "hello-world:latest",
"memory": 400
}
],
requiresCompatibilities=["FARGATE"],
networkMode="awsvpc",
cpu="256",
memory="512"
)["taskDefinition"]
{'taskDefinitionArn': 'arn:aws:ecs:us-east-1:************:task-definition/moto:2',
'containerDefinitions': [{'name': 'hello_world',
'image': 'hello-world:latest',
'cpu': 0,
'memory': 400,
'portMappings': [],
'essential': True,
'environment': [],
'mountPoints': [],
'volumesFrom': []}],
'family': 'moto',
'networkMode': 'awsvpc',
'revision': 2,
'volumes': [],
'status': 'ACTIVE',
'requiresAttributes': [{'name': 'com.amazonaws.ecs.capability.docker-remote-api.1.18'},
{'name': 'ecs.capability.task-eni'}],
'placementConstraints': [],
'compatibilities': ['EC2', 'FARGATE'],
'requiresCompatibilities': ['FARGATE'],
'cpu': '256',
'memory': '512'}
```
This change adds several default keys to the task based on those two
real responses and the AWS documentation:
https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html
The mock still doesn't match the real response exactly but it's much
closer than it was before.
* Pass the "default" cluster
* Mock ECS exceptions more accurately
Moto's mock ECS has drifted fairly far from the actual ECS API in terms
of which exceptions it throws. This change begins to bring mock ECS's
exceptions in line with actual ECS exceptions. Most notably:
- Several custom exceptions have been replaced with their real ECS
exception. For example, "{0} is not a cluster" has been replaced with
ClusterNotFoundException
- Tests have been added to verify (most of) these exceptions work
correctly. The test coverage was a little spotty to begin with.
- The new exceptions plus the change to pass the "default" cluster
exposed a lot of places where mock ECS was behaving incorrectly. For
example, the ListTasks action is always scoped to a single cluster in
ECS but it listed tasks for all clusters in the mock. I've minimally
updated the tests to make them pass, but there's lots of opportunity to
refactor both this method's test and its implementation.
This does not provide full coverage of exceptions. In general, I ran
these operations against actual ECS resources and cross-referenced the
documentation to figure out what actual exceptions should be thrown and
what the messages should be. Consequently, I didn't update any
exceptions that took more than trivial amount of time to reproduce with
real resources.
* 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>
* initial implementation of taskSets. Fixed a bug with ECS Service where task_definition was a required parameter.
* Added update_task_set and tests. DRYed up ClusterNotFoundException. General cleanup.
* Added support for filtering tags on include parameter to describe_task_sets. Added additional tests.
* Fix copy/pasta in ClusterNotFoundException
* styling updates
* Added TODO for delete_task_set force parameter
* Updated multiple function and constructor calls to use named variables. Updated tests to reference variables instead of hardcoded strings.
* Run black for formatting
* Updated create_service function call to use named variables
AWS defines this option as:
```
--family-prefix (string)
The full family name with which to filter the ListTaskDefinitions
results. Specifying a familyPrefix limits the listed task
defini-tions to task definition revisions that belong to that
family.
```
This option behaves differently than ecs:ListTaskDefinitionFamilies.
Instead of doing a comparison like `startswith`, it does a full string
comparison by matching the entire task definition family to the prefix.
For example, let's say there exists a task definition with the family
`super-cool-task-def`.
ListTaskDefinitionFamilies would look like this:
```
aws ecs list-task-definition-families --family-prefix super-cool
{
"families": [
"super-cool-task-def"
]
}
```
ListTaskDefinitions would look like this:
```
aws ecs list-task-definitions --family-prefix super-cool
{
"taskDefinitionArns": []
}
```
Before when a task definition revision was de-registered all revisions
after that changed their revision id. This doesn't match the way it is
handled in AWS. Using a hash and manually increment the revision id
solves that.
