#pr-reviews (2021-05)

I don’t want to ignore the desired count in my ecs service tho

and the lifecycle meta argument does not allow variable interpretation

the only way you could do it, is if you added a new aws_ecs_service that could be toggled but since youd also have to account for ignore the task definition or not ignoring the task definition, you have to add 2 new aws_ecs_service resources…….

it would be easier to create a toggle to disable the creation of the ecs service inside the tf module and simply create it outside of the module definition and then you can ignore changes on any resource argument you like

but… at that point, you might as well just use custom tf code… oof this is where terraform kind of stinks

if you set the var.desired_count = null, does it ignore the input auto-magically ?

:thinking_face: I see. Yeah I understand that there are use-cases when you’d want to set the desired count every time.

So desired count defaults to 0 … And you specify the min & max through aws_appautoscaling_target resource…

Let me see if I set that back to default/null what happens

I have a feeling this isn’t going to work though, as the docs specifically point out ignoring desired_count https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_service#ignoring-changes-to-desired-count

But worth testing it nonetheless!

Nope I set it to null and its set desired_count to 0! Not one for production then

Ok we’ve closed the PR. Will have to write some custom TF code then I guess

It’s a difficult issue to solve but worth discussing. The method of creating 2 new ecs service resources with the desired permutations of (3) ignoring desired count and (4) ignoring desired count and task def (where (1) is ignoring nothing and (2) is ignoring the task def) might be the only option here

Agreed. It doesn’t look like terraform will allow interpolations in the lifecycle block anytime soon (I can only assume this is a complex thing to do). Looks like the issue was first raised in 2015

I wouldn’t want to end up in a scenario where we have loads of ECS services declared though for every possible combination, that would be a maintenance nightmare. Seems like being able to specify lifecycle attributes at the module level would be best (https://github.com/hashicorp/terraform/issues/27360)

I’ll go with creating the 4 different permutations for now and hope that this would be better solved in the future

This is ready for a re-review now

@RB is there any chance I could get this reviewed please?

i ran the tests but the tests failed. please take a look when time permits

@RB Please can you take another look, cheers

Any chance we can get a stamp of approval on this one?

The tests all passed on this one, can we get an approval please?

It hurts to approve that one but no one can think of an alternative other than using custom terraform. The module now has 4 ecs service resources with copied and pasted terraform resource inputs

Yeah until terraform make the lifecycle of a resource configurable at the module level I don’t think theres much we can do. Right now this change is breaking for us anyway (We need to terraform state mv from the old location to the new). If the underlying terraform resource for the ECS service ignored the value of desired count if its null that would have avoided this whole issue but what can you do

thank you @Matt Gowie!

can we get this in? it’s green