[Enhancement]: Control when aws_ecs_task_execution is executed

[bryantbiggs]

Description

Carrying over from here since the PR will close once the release is created #29783

Executing the RunTask API call on each read will inevitably be problematic. This issue is to brainstorm and chat about possible further enhancements that would give users more control over when tasks are run, or re-run.

Affected Resource(s) and/or Data Source(s)

• aws_ecs_task_execution data source

Potential Terraform Configuration

resource "aws_ecs_task_execution" "everytime" {
  cluster         = aws_ecs_cluster.test.id
  task_definition = aws_ecs_task_definition.test.arn
  desired_count   = 1
  launch_type     = "FARGATE"
  network_configuration {
    subnets          = aws_subnet.test[*].id
    security_groups  = [aws_security_group.test.id]
    assign_public_ip = false
  }

  triggers = {
    everytime = timestamp()
  }
}

resource "aws_ecs_task_execution" "flag" {
  cluster         = aws_ecs_cluster.test.id
  task_definition = aws_ecs_task_definition.test.arn
  desired_count   = 1
  launch_type     = "FARGATE"
  network_configuration {
    subnets          = aws_subnet.test[*].id
    security_groups  = [aws_security_group.test.id]
    assign_public_ip = false
  }

  triggers = {
    flag = true # flip to false to re-run
  }
}

References

#29783

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[md5]

It feels like there is already a decent amount of control of when you do want an execution to happen using either reference_id to provide a reference ID that only changes when your logic dictates (perhaps based on an external variable set by a CI pipeline, or based on timestamp() as in your example if you want it to invoke whenever the other arguments are resolvable, whether during plan or apply) or by using replace_triggered_by.

For me, what I really want is to ensure that this does not run during plan, only during apply. For that, I feel like the same duality that we currently have between data "aws_lambda_invocation" and resource "aws_lambda_invocation" would be helpful. In other words, I would like to see resource "aws_ecs_task_execution" introduced alongside data "aws_ecs_task_execution" so that I know that the RunTask invocation will only happen during an apply.

[md5]

I have created #29978 as a possible next step

[seanamos]

I'm try to figure out what was the original use case to create this as a data source that might run during plans and might run during applies, instead of only during applies. Highly counter-intuitive.

A resource with a trigger of some kind just seems the most obvious.

[seanamos]

My less than ideal, but functional workaround for this.

Create a very simple lambda that does an ECS RunTask. Use resource "aws_lambda_invocation" to kick off the lambda.
Same use case as many people, some services running on ECS that need their DB migrations run before their new versions roll out.