Skip to content

task_definition version always known after apply #72

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
TarekAS opened this issue Aug 22, 2019 · 9 comments
Closed

task_definition version always known after apply #72

TarekAS opened this issue Aug 22, 2019 · 9 comments

Comments

@TarekAS
Copy link

TarekAS commented Aug 22, 2019

Hello,

While using this module, I get the following message every time I do terraform apply.

~ resource "aws_ecs_service" "atlantis" {
        cluster                            = "arn:aws:ecs:eu-west-1:[REDACTED]:cluster/atlantis"
        deployment_maximum_percent         = 200
        deployment_minimum_healthy_percent = 50
        desired_count                      = 1
        enable_ecs_managed_tags            = false
        health_check_grace_period_seconds  = 0
        iam_role                           = "aws-service-role"
        id                                 = "arn:aws:ecs:eu-west-1:[REDACTED]:service/atlantis"
        launch_type                        = "FARGATE"
        name                               = "atlantis"
        platform_version                   = "LATEST"
        propagate_tags                     = "NONE"
        scheduling_strategy                = "REPLICA"
        tags                               = {}
      ~ task_definition                    = "atlantis:2" -> (known after apply)

Is there any way to avoid this?

The following is my module usage:

module "atlantis" {
  source  = "terraform-aws-modules/atlantis/aws"
  version = "~> 2.0"

  name               = "atlantis"
  vpc_id             = "${aws_vpc.myvpc.id}"
  private_subnet_ids = ["${aws_subnet.private-1a.id}", "${aws_subnet.private-1b.id}", "${aws_subnet.private-1c.id}"]
  public_subnet_ids  = ["${aws_subnet.public-1a.id}", "${aws_subnet.public-1b.id}", "${aws_subnet.public-1c.id}"]

  certificate_arn       = "redacted"
  create_route53_record = false

  atlantis_github_user       = "${local.atlantis_github_username}"
  atlantis_github_user_token = "${local.atlantis_github_access_token}"
  atlantis_repo_whitelist    = ["redacted"]

  ssm_kms_key_arn = "redacted"
}
@jondunning
Copy link

Having the same issue

@jseiser
Copy link
Contributor

jseiser commented Nov 21, 2019

Same issue present in my deployments as well.

@wreulicke
Copy link

I have same issue.

I seem that this issue is caused by this PR.
#62

@wreulicke
Copy link

@antonbabenko
What do you think?

tomwj added a commit to tomwj/terraform-aws-atlantis that referenced this issue May 13, 2020
Using a data provider prevents terraform converging forcing an update on every apply. It doesn't have the data available since it's pulling from AWS when it has it locally already. https://www.terraform.io/docs/configuration/data-sources.html#data-resource-dependencies
tomwj added a commit to tomwj/terraform-aws-atlantis that referenced this issue May 13, 2020
Using a data provider prevents terraform converging forcing an update on every apply. It doesn't have the data available since it's pulling from AWS when it has it locally already. https://www.terraform.io/docs/configuration/data-sources.html#data-resource-dependencies
@tomwj
Copy link

tomwj commented May 13, 2020

tomwj@22a4b64

Fix issue #72 task_definition known after apply

Using a data provider prevents terraform converging. Basically until the apply runs it doesn't have the data to know which revision is great. Forcing it to be updated on every apply. It doesn't have the data available since it's pulling from AWS when it has it locally already.

It does mean if you update the task_definition in the AWS console this will overwrite it. Which I believe is correct behaviour. e.g. I bumped the task_definition manually to 16 and it will roll it back.

    ~ task_definition                    = "atlantis:16" -> "atlantis:15"

https://www.terraform.io/docs/configuration/data-sources.html#data-resource-dependencies

tomwj added a commit to tomwj/terraform-aws-atlantis that referenced this issue May 13, 2020
Using a data provider means terraform doesn't have the information required until runtime to determine if the `task_definition` needs to be updated. Subsequently an update is triggered on every `apply`. It has the information locally already, by removing the indirection of a data provider terraform can correctly reconcile if any updates are required prior to `apply` being run. Essentially it's making the dependency between the `aws_ecs_service` and `aws_ecs_task_definition` explicit rather than implied through the `data` provider and `depends_on`

https://www.terraform.io/docs/configuration/data-sources.html#data-resource-dependencies

Currently atlantis shows an update everytime a plan or apply is run despite o configuration changes.
terraform-aws-modules#72

None that I'm aware of.

- Confirmed that updating the vars that are used in the `task_definition` trigger an update
- Manually create a new task_definition revision and confirm that terraform will role back to the

AWS, plan/apply and manual changes
@thyming
Copy link

thyming commented May 18, 2020

does anyone have a workaround for this issue?

domcleal added a commit to domcleal/terraform-aws-atlantis that referenced this issue Oct 30, 2020
…m-aws-modules#72)

A data lookup for the latest task definition revision to be used in the
ECS service was enabled by default, which continually appeared in
plans/applies.

This is used when the task definition's updated by an external
deployment tool, so this is now disabled and requires enabling the
`external_task_definition_updates` variable so the default behaviour is
quiet.
domcleal added a commit to domcleal/terraform-aws-atlantis that referenced this issue Oct 30, 2020
…m-aws-modules#72)

A data lookup for the latest task definition revision to be used in the
ECS service was enabled by default, which continually appeared in
plans/applies.

This is used when the task definition's updated by an external
deployment tool, so this is now disabled and requires enabling the
`external_task_definition_updates` variable so the default behaviour is
quiet.
@rotarur
Copy link

rotarur commented Dec 3, 2020

I have the same issue. i think depends_on can be safely removed as it is referenced in another resource to be used.
I did it in my tests and the plan doesn't show any changes:

data "aws_ecs_task_definition" "atlantis" {
   task_definition = var.name
}

@rpdelaney
Copy link

Looks like this was fixed in #163

@github-actions
Copy link

github-actions bot commented Nov 8, 2022

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants