Taskdef constraints

[allisaurus]

Fixes issue described in this comment.

test output

docker-compose.yml

version: '2'
services:
  database:
    image: httpd:2.4
    ports:
      - "80:80"
    environment:
      - ENV1=test

ecs-params.yml

version: 1
task_definition:
  placement_constraints:
    - type: memberOf
      expression: "attribute:ecs.os-type == linux"
    - type: memberOf
      expression: "attribute:ecs.instance-type == t2.micro"
run_params:
  task_placement:
    constraints:
      - type: memberOf
        expression: "attribute:ecs.os-type == linux"

cmd output:

> ecs-cli.exe compose service up
�[36mINFO�[0m[0000] Using ECS task definition                     �[36mTaskDefinition�[0m="placement:5"
�[36mINFO�[0m[0000] Updated the ECS service with a new task definition. Old containers will be stopped automatically, and replaced with new ones  �[36mdesiredCount�[0m=1 �[36mforce-deployment�[0m=false �[36mservice�[0m=placement
�[36mINFO�[0m[0015] Service status                                �[36mdesiredCount�[0m=1 �[36mrunningCount�[0m=1 �[36mserviceName�[0m=placement
�[36mINFO�[0m[0015] (service placement) has started 1 tasks: (task 97e72ca4-bf1b-47dc-a7b0-77287f945cfc).  �[36mtimestamp�[0m="2019-08-28 21:16:25 +0000 UTC"
�[36mINFO�[0m[0015] (service placement) has reached a steady state.  �[36mtimestamp�[0m="2019-08-28 21:16:35 +0000 UTC"
�[36mINFO�[0m[0015] ECS Service has reached a stable state        �[36mdesiredCount�[0m=1 �[36mrunningCount�[0m=1 �[36mserviceName�[0m=placement

resulting task definition with constraints:

{
    "taskDefinition": {
        "taskDefinitionArn": "arn:aws:ecs:us-west-2:##########:task-definition/placement:7",
        "containerDefinitions": [
            {
                "name": "database",
                "image": "httpd:2.4",
                "portMappings": [
                    {
                        "containerPort": 80,
                        "hostPort": 80,
                        "protocol": "tcp"
                    }
                ],
                "essential": true,
                "environment": [
                    {
                        "name": "ENV1",
                        "value": "test"
                    }
                ]
            }
        ],
        "family": "placement",
        "revision": 7,
        "status": "ACTIVE",
        "requiresAttributes": [
            {
                "name": "com.amazonaws.ecs.capability.docker-remote-api.1.17"
            },
            {
                "name": "com.amazonaws.ecs.capability.docker-remote-api.1.18"
            }
        ],
        "placementConstraints": [
            {
                "type": "memberOf",
                "expression": "attribute:ecs.os-type == linux"
            },
            {
                "type": "memberOf",
                "expression": "attribute:ecs.instance-type == t2.micro"
            }
        ],
        "compatibilities": [
            "EC2"
        ],
        "cpu": "512",
        "memory": "2048"
    }
}

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing

• Unit tests passed
• [TBD] Integration tests passed
• Unit tests added for new functionality
• Listed manual checks and their outputs in the comments (example)
• [n/a] Link to issue or PR for the integration tests:

Documentation

• Contacted our doc writer
• Updated our README

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[allisaurus]

CC @vadimi

[iamhopaul123]

LGTM

[SoManyHs]

Would it make sense to add an error case for wrong type of constraint/nil checking?

[allisaurus]

Right now we're passing all given values through to ECS and letting it validate, to prevent needing to change logic if/when new constraint types are allowed. To show nils are passed in & handled correctly by ECS though, I'll add some test output to the PR.

[SoManyHs]

Observation: I'm tempted to say if this is always "memberOf" to not include it at all but since we're reusing the Constraint struct, plus maybe we have to account for future constraint types, this should be fine.

[allisaurus]

test: nil constraint (ECS returns client error)

ecs-params.yml

version: 1
task_definition:
  placement_constraints:
    - type:
      expression:

cmd output:

>ecs-cli.exe compose service up
�[31mERRO�[0m[0000] Error registering task definition             �[31merror�[0m="ClientException: constraint.type should not be null or empty.\n\tstatus code: 400, request id: b34eecf5-###-4d00-9494-eef593d97142" �[31mfamily�[0m=placement
�[31mERRO�[0m[0000] Create task definition failed                 �[31merror�[0m="ClientException: constraint.type should not be null or empty.\n\tstatus code: 400, request id: b34eecf5-###-4d00-9494-eef593d97142"
�[31mFATA�[0m[0000] ClientException: constraint.type should not be null or empty.
        status code: 400, request id: b34eecf5-###-4d00-9494-eef593d97142

test: nil expression (ECS returns client error)

ecs-params.yml

version: 1
task_definition:
  placement_constraints:
    - type: memberOf
      expression:

cmd output:

> ecs-cli.exe compose service up
�[31mERRO�[0m[0000] Error registering task definition             �[31merror�[0m="ClientException: constraint.expression should not be null or empty.\n\tstatus code: 400, request id: e7bbb9dd-###-43e9-b431-c452ac5b85b1" �[31mfamily�[0m=placement
�[31mERRO�[0m[0000] Create task definition failed                 �[31merror�[0m="ClientException: constraint.expression should not be null or empty.\n\tstatus code: 400, request id: e7bbb9dd-###-43e9-b431-c452ac5b85b1"
�[31mFATA�[0m[0000] ClientException: constraint.expression should not be null or empty.
        status code: 400, request id: e7bbb9dd-###-43e9-b431-c452ac5b85b1