Is it possible to know if a resource is being created or not and use that in some way

Terraform
1

TL;DR; Is there anything within terraform that can answer true/false to the question of if a terraform resource is being replaced (new created / old destroyed, rather than an inline update), to allow me to use that information in the following way.

resource "aws_autoscaling_group" "asg" {
  name                 = format("asg-%s - %s", var.group_name, aws_launch_configuration.lc.name)
  launch_configuration = aws_launch_configuration.lc.name
  vpc_zone_identifier  = var.private_subnets
  min_elb_capacity     = var.min_asg_count
  min_size             = var.min_asg_count
  max_size             = var.max_asg_count
  desired_capacity     = module.current_desired_capacity.result + aws_launch_configuration.lc.isNew ? 5 : 0

sort of thing.

We’re running within AWS, but the concept should be applicable to any Terraform resource where a new one is created and the old one destroyed.

When we deploy a new AMI, we update a variable and that variable is used to force a new Launch Configuration, and that cascades a whole set of new resources (ASG, Cloudwatch Alarms for scaling, etc.), and when they are all active, the old ones are destroyed. We already have in place a mechanism to get the current number of EC2s running so that the new group has the same desired capacity when the new ASG launches. All works perfectly.

The repo that contains all of this includes additional aspects associated with deploying an AMI, but not necessarily amended every time.

One thing we’ve noticed is that we have a small additional spike in CPU usage across the AutoScalingGroup when we deploy a new AMI, so we want to add a few more EC2 instances above the current desired capacity but only if we’re doing a launch.

So, we know that the Launch Configuration changing is going to be the trigger for requiring additional EC2s.

What we don’t want to have happen is when we make a change to resources that do not warrant a new Launch Configuration, to not increase the desired capacity beyond what is currently being used.

2

Hi @rquadling,

Unfortunately I think the short answer to this nuanced question is “no”: Terraform is a desired-state system, and so making decisions based on the prior state is not a part of its model.

(There is some subtlety to my statement above. Terraform itself, via logic in providers, is of course taking into account the prior state in order to produce a plan of action. But that behavior is not programmable in the Terraform language itself. Instead, from the perspective of the Terraform configuration it’s an implementation detail.)

However, that doesn’t mean you can’t use a Terraform configuration as a building block for a larger system which solves this problem. If you can write some wrapper software that implements the logic you’re describing in order to generate a different desired state based on these different criteria you described here then you can use Terraform just as the engine to achieve that desired state, by declaring some input variables that model the different possibilities and then having your wrapper program set those variables differently depending on what action needs to be taken.

3

I will use a different tool but maybe you can user dependencies, tags, data sources and ifs.

4

I’m using our AWS CLI module to get the currently running AMI-ID and that is working well for us at the moment. It does mean external module call and some temp files … nothing too bad.