packer fails to validate deprecate_at unless it's a literal string

[saxonww]

Overview of the Issue

I am using the amazon-ebs builder with the amazon-ami data source, to build a custom AMI based off an existing upstream AMI.

I've found that I can't run packer validate if I set deprecate_at to anything other than a literal string. My upstream AMI is replaced on a schedule, so I wanted to set deprecate_at to e.g. timeadd(data.amazon-ami.source.creation_date, duration). But when I do, I get an error like the following:

Error: 1 error(s) occurred:

* deprecate_at is not a valid time. Expect time format: YYYY-MM-DDTHH:MM:SSZ

I think this is a bug:

• If I cause the result to be written to a file instead, I see that the written date/time matches the expected format.
• If I replace timeadd(...) with the value written to the file, it validates.
• If I replace timeadd(data.amazon-ami...) with timeadd(timestamp(), ...), it validates.
• If I just run packer build example.pkr.hcl it works fine, setting the expected deprecation time.

This blocks me because my CI routine runs packer validate on the template, so even though packer build would work, CI fails. I would have to work around it by calculating the deprecation_time outside Packer and passing the result in as a variable.

Maybe this is a Packer problem? The data source is not evaluated by packer validate, and the parameter expects a particularly-formatted string, so there would be no way to ensure a calculated value is valid. I wonder if, instead of failing to validate, this could issue a warning instead?

Reproduction Steps

See gist at https://gist.github.com/saxonww/d237f1ff2a3292cf916b02d85eca8cb5

Plugin and Packer version

Packer v1.10.1

Plugin version v1.3.2

Simplified Packer Buildfile

See gist at https://gist.github.com/saxonww/d237f1ff2a3292cf916b02d85eca8cb5

Operating system and Environment details

A Docker container based on the following:

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Architecture is x86_64.

Log Fragments and crash.log files

Setting PACKER_LOG=1 doesn't yield anything useful.

[lbajolet-hashicorp]

Hi @saxonww,

Looks like formatdate may help you there? Have you tried something like formatdate("YYYY-MM-DDTHH:MM:SSZ", timeadd(data.amazon-ami.source.creation_date, duration))? This will format the timestamp returned by timeadd to the format that the attribute expects.

The data source is not evaluated during validate unless you use the -evaluate-datasources flag indeed, but the configuration is still validated (there are two passes for most entities, Prepare/Validate, and Run/Execute), packer validate will run the prepare step, which ensures the values are valid.

Regarding "Can it be a warning instead of an error", this may be possible, but I would advise against it, as the attribute is expected to be a date formatted exactly as it is, so if a user provides a misformatted date, I believe it is best that the plugin fails as quickly as possible instead of going into undefined behaviour territory. Especially if running in CI, warnings are easily missed, whereas errors will fail the build, prompting some investigation.

Note: scratch all that, I misunderstood the question, but the information may still interest someone who stumbles on this thread.
If I understand correctly here, the problem stems from the datasource not being evaluated, and the value being checked during validate, which is somewhat expected then. Plugins don't know if we're running validate/build, therefore they assume they're receiving a complete configuration to run a build with, hence the error here.
In your case for those CI runs, I would suggest maybe using the --evaluate-datasources flag when invoking packer validate, this way your datasource should be able to return valid values. This does have the drawback of potentally having a cost if the requests are billed