Timestamp should be available in terraform configs

[ulfbrehmer]

Like in Packer, where I can use {{timestamp}}, it would be very convenient to be able to use a timestamp variable, for example when naming a new resource. For instance, an AWS launch configuration might be named like thus:

name = "terraform-lc-${var.timestamp}"


At the moment, I have had to first create a variable definition in my .tf file

variable "timestamp" {
default = "unknown"
}


and override the default value with an environment variable when calling terraform on the command line:

$ export datevar=$(date +%s);terraform apply -var "timestamp=${datevar}"


This is quite clumsy, so it would be nice to be able to do in a cleaner way.

[rcostanzo]

The timestamp function itself is straight-forward. But the tricky part is we'd need to extend terraform's core diff capabilities when deciding if an update is needed. Otherwise, any resource attribute you use a timestamp in will always appear to need to be modified. We'd need some kind of token in the state file to signify a wildcard match for that part of the value so the time itself doesn't need to match.

[armon]

Yep exactly. Having a timestamp that changes every time will make TF very trigger happy

[gposton]

👍 I'd like to see this as I often run into naming collision when using create_before_destroy

[phinze]

In the recent versions of Terraform we've gained the facility to do unique ID generation on a per-attribute basis and we've used it to do make names like can collide (like launch configuration names) optional.

In my mind, this solves the root issue behind @ulfbrehmer's desire to have a timestamp from within terraform config. Of course there are probably other use cases where having the current time might be useful (like a "created at tag" perhaps), but I did want to mention that the name-collision issue is being addressed separately.

[jasonkeene]

👍 This would be very useful.

[phinze]

Quick update here - we'll need to implement #2018 to prevent "trigger happiness" - after which this becomes a much more reasonable feature to add. 👍

[apparentlymart]

Rather than having an interpolation that expands to the current system timestamp, could this instead be handled by exposing a mechanism to interpolate timestamps relating to particular resources? If there were a way to interpolate the time when a particular resource was created, and the time when a particular resource was updated, then this could avoid the diff flappiness that results from locking on to a constantly-changing property like the system time.

Probably shouldn't be a variable within the resources themselves, since that would collide with the per-resource attributes and would make it impossible to reference a resource timestamp from within the resource itself, but perhaps it could be exposed in a separate namespace like meta.aws_instance.web.created_time and meta.aws_instance.web.updated_time. Perhaps there could also be a meta.self shorthand to help with the common case of interpolating a resource's timestamp into its own attributes.

This would of course require the state to be extended to track these additional values, and would require some careful sequencing so that e.g. the created time is set to the current system time before interpolating a not-yet-created resource.

I could see also including something like meta.aws_instance.web.unique_id, which expands to a unique id assigned at resource creation time that is guaranteed to change when a resource is re-created. This would be somewhat like updated_time but could include more than just time to improve the uniqueness guarantee. This would serve to generalize the unique id mechanism @phinze mentioned above so that it can be applied to any attribute of any resource.

[packplusplus]

+1, same issue as @gposton. I've been doing some hacks with while loops in the meantime to minimize churn in my as_configs. Works great provided I get the loop started.

I think the feature should include interpolating timestamps of files.

In the shell I'm terraforming (could be a nohup / screen / tmux / whatever, but I leave terms open forever). Keep each lc in their own file.

cd /path/tf/files
#this is bsd stat. gnu stat would require some nonsense  from the looks of it.  
while : ; do printf %s "$(stat -f '%Sm' -t '%Y%m%d%H%M' launch_config.tf)" > .launch_config.date; sleep 5; done &

Then in my tf files.

resource "aws_launch_configuration" "lc_conf" {
  name = "launch_config-${file(\".launch_config.date\")}"
  image_id = "ami-1234"
  instance_type = "m1.small"
}

p.s. FWIW #2018 was closed a couple days ago, so maybe this is already in the works.

[phinze]

That's an interesting thought @apparentlymart - my first reaction is that I'd love to be able to simply reference something maintained in the upstream provider rather than having Terraform doing all the work to keep track of the timestamps. But I can see the benefit of getting global support for it.

I think having a simple timestamp() interp function like we're discussing in #3326 is the easy win (and should be sufficient to close this particular issue), but I think these common global attributes are worth considering further for sure.

[ricardclau]

👍 here

My particular issue is whenever you are setting up an AWS Autoscaling group with an associated config. If the config changes and you are setting a static name, Terraform errors as configs cannot be modified but need to regenerate.

At the moment I am creating my launch configuration like this:

resource "aws_launch_configuration" "influxdb_test_conf" {
    name = "influxdb-terraform-test-${var.timestamp}"
    image_id = "${var.ubuntu_ami}"
    instance_type = "${var.instance_type}"
    key_name = "${var.aws_key_name}"
}

but of course I need to supply the timestamp variable

If there is a better way to sort this issue I am all ears :)

[packplusplus]

@ricardclau Not specifying a name makes terraform auto gen a name for you. No collisions. I started using name_prefix. Not as nice as a timestamp, but it seems perfectly cromulent.

[ricardclau]

Thanks @packplusplus that should do the trick in terms of no name collisions

The problem I am having now is that terraform errors when applying the new config as apparently it is trying to delete the old config before applying a new one (or AWS is slow to react)

Have you ever encountered this issue? Should I open a bug? The change I am doing is just changing the ec2 instance type as a quick test

[packplusplus]

@ricardclau look at lifecycles. Add lifecycle { create_before_destroy = true } to your aws_launch_configuration.

[ricardclau]

Wow, sorry about my impatience and not reading the full docs, thank you very much for the quick and accurate answer @packplusplus ! (Terraform newbie here)

[iceycake]

Sorry for late into the discussion. My use case of the timestamp function could be a nice touch for description like KMS key description or S3 bucket / Object Key name.

[phinze]

Just noting here that ignore_changes has landed, so a PR for a timestamp() interpolation function would be welcome!

[glasser]

Something similar to this that would make me happy would just be changing name_prefix (ie, resource.PrefixedUniqueId) to add a timestamp before the random part. Then you'd be able to sort your ASGs/launch configurations but it still shouldn't cause any diff-happiness issues.

[baskaran-md]

Any updates on this timestamp() interpolation function?

[josephholsten]

In #3326 there is mention of rcostanzo@e6e6e46, do we need anything other than a PR with that?

@phinze?

[mitchellh]

Done with #10475.

There are additional methods of getting time that will come to Terraform post-0.8.

[ghost]

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.