Skip to content
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

[Enhancement]: Control when aws_ecs_task_execution is executed #29871

Open
bryantbiggs opened this issue Mar 8, 2023 · 6 comments
Open

[Enhancement]: Control when aws_ecs_task_execution is executed #29871

bryantbiggs opened this issue Mar 8, 2023 · 6 comments
Labels
enhancement Requests to existing resources that expand the functionality or scope. proposal Proposes new design or functionality. service/ecs Issues and PRs that pertain to the ecs service.

Comments

@bryantbiggs
Copy link
Contributor

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

@bryantbiggs bryantbiggs added enhancement Requests to existing resources that expand the functionality or scope. needs-triage Waiting for first response or review from a maintainer. labels Mar 8, 2023
@github-actions github-actions bot added the service/ecs Issues and PRs that pertain to the ecs service. label Mar 8, 2023
@github-actions
Copy link

github-actions bot commented Mar 8, 2023

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
Copy link
Contributor

md5 commented Mar 9, 2023

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.

@justinretzolk justinretzolk added proposal Proposes new design or functionality. and removed needs-triage Waiting for first response or review from a maintainer. labels Mar 9, 2023
@md5
Copy link
Contributor

md5 commented Mar 14, 2023

I have created #29978 as a possible next step

@seanamos
Copy link

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
Copy link

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.

@Ocramius
Copy link

Ocramius commented Sep 9, 2024

My less than ideal, but functional workaround for this.

Having to go through Lambda is viable, but really a never-ending chore that involves introducing a ton of complexity too.

Would love to have the "output of an ECS task" as a local resource, effectively.

In #1703, @bflad used the local-exec workaround:

resource "aws_ecs_task_definition" "example" {
  # your task configuration here
}

resource "null_resource" "ecs-run-task" {
  provisioner "local-exec" {
    # add other args as necessary: https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html
    command     = "ecs run task --task-definition ${aws_ecs_task_definition.example.arn}"
    interpreter = ["aws"]
  }
}

This is relatively elegant, IMO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Requests to existing resources that expand the functionality or scope. proposal Proposes new design or functionality. service/ecs Issues and PRs that pertain to the ecs service.
Projects
None yet
Development

No branches or pull requests

5 participants