pulumi-aws icon indicating copy to clipboard operation
pulumi-aws copied to clipboard

Update ECS Service only when TaskDefinition is changed locally in pulumi

Open ypresto opened this issue 5 years ago • 4 comments

I created ECS Service and initial TaskDefintion with pulumi, then I set up automatic deployment (creating new task definition and update service from CI).

In this configuration, how do I achieve both of 1 and 2?:

  1. When pulumi up without change, expects no change.
  2. When pulumi up with change on task definition, expects updating Service.

pulumi/pulumi-awsx#856 suggests ignoreChanges but it does not solve the second case. Maybe we need to have ignoreChanges with function, to ignore only when updating revision is older than the state.

Current behavior of pulumi up after task def & service are updated by automatic deployment:

When I made NO changes to task def and without ignoreChanges

        ~ aws:ecs/service:Service: (update)
            [id=...]
            [urn=...]
            [provider=...]
          ~ taskDefinition: "arn:aws:ecs:ap-northeast-1:XXXXXXXXXXXX:task-definition/our-app-rails:5" => "arn:aws:ecs:ap-northeast-1:711533999350:task-definition/our-app-rails:4"

Pulumi is reverting task definition revision of service, even after pulumi refresh (Use Case of pulumi/pulumi-awsx#856)

When I made SOME changes to task def and with ignoreChanges (in transformations

     └─ awsx:x:ecs:FargateTaskDefinition  rails
 +-     └─ aws:ecs:TaskDefinition         rails           replace     [diff: ~containerDefinitions]

and no Service update.

ypresto avatar Feb 25 '20 17:02 ypresto

Or can I configure pulumi to always reference the "latest" revision of a resource?

ypresto avatar Feb 26 '20 11:02 ypresto

Could you please provide a working example of what you're doing? I tried to reproduce this behavior with a FargateTaskDefinition but my second pulumi up came back with no diff as expected.

leezen avatar Feb 27 '20 07:02 leezen

This following code will reproduce the issue:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

let booleanItem: boolean | undefined;

const cluster = new aws.ecs.Cluster("diff-cluster");
const task = new aws.ecs.TaskDefinition("diff-task", {
    cpu: "256",
    memory: "512",
    requiresCompatibilities: ["FARGATE"],
    containerDefinitions: JSON.stringify([{
        name: "nginx-diff",
        image: "nginx",
        cpu: 256,
        portMappings: [{
            containerPort: 80
        }],
        environment: [
            {
                name: "name1",
                value: "this-value"
            },
            {
                name: "boolean-test",
                value: booleanItem // booleanItem ?? "" resolves the issue.
            }
        ]
    }]),
    networkMode: "awsvpc",
    family: "diff-task"
});

phillipedwards avatar Jan 19 '22 22:01 phillipedwards

When I run the repro from @phillipedwards for the second time, this is the essence of the diff that I get:

                  ~ environment : [
                      + [1]: {
                              + name: "boolean-test"
                            }
                    ]

This means that the environment variable with an undefined value got ignored (makes sense) but now the provider calculates the difference as if it was meaningful.

I believe this is specific to the provider implementation, so I'll move the issue to pulumi-aws.

mikhailshilkov avatar May 30 '22 15:05 mikhailshilkov

This means that the environment variable with an undefined value got ignored (makes sense) but now the provider calculates the difference as if it was meaningful.

This is due to the design of the upstream provider diff implementation - which does some normalization on containerDefinitions, but does not normalize empty values. You must either leave off env vars that are undefined, or specify them with the empty string value. The request to handle this and similar issues more specifically in the upstream provider is https://github.com/hashicorp/terraform-provider-aws/issues/11526.

lukehoban avatar Nov 19 '22 04:11 lukehoban