locals {
token_emails = {
for k, v in yamldecode(file(var.token_email_file)) :
k => coalesce(v, {})
}
_token_expire = { for k, v in local.token_emails :
k => format("(expire: %s)", time_rotating.token[k].rfc3339)
if contains(keys(v), "expires")
}
token_label = { for k, v in local.token_emails :
k => join(" ", compact([
k,
lookup(local._token_expire, k, null),
]))
}
}
resource "dockerhub_token" "token" {
for_each = local.token_emails
label = local.token_label[each.key]
scopes = ["repo:read"]
}
# Track expiration for items with defined expiration
resource "time_rotating" "token" {
for_each = { for k, v in local.token_emails :
k => v if contains(keys(v), "expires")
}
rotation_rfc3339 = each.value.expires
}
Expected Behavior
Once the fixed expiration date has passed, I expect the basis time to be updated, indicating that the rotation does not need to happen again.
Actual Behavior
Upon passing the expiration date, the basis time is updated as expected. However, rotations continue to happen repeatedly on all subsequent applies. I haven't looked at the code, but presumably this is because the comparison is against the current time / plan time instead of the resource basis time / ID.
Steps to Reproduce
create a time_rotating element with a fixed rotation date
wait until after the date has passed
???
profit
How much impact is this issue causing?
Medium
Logs
No response
Additional Information
The documentation does somewhat indicate that "When the current time has passed the rotation timestamp, the resource will trigger recreation", but it's not entirely clear if that means "every single apply". I mean, that's definitely what happens, but it seems that a singular rotation is what's expected by reading "This prevents perpetual differences" in the documentation. So either the documentation should be updated with a warning that setting [rotation_rfc3339](https://registry.terraform.io/providers/hashicorp/time/latest/docs/resources/rotating#rotation_rfc3339) in the past will cause perpetual differences, or the code should be updated to only trigger a single rotation upon passing the fixed rotation date.
I suppose adding a parameter like "rotate_once" with a default of false (or a "rotation_count" with a default like -1 to communicate infinite rotations, and a decrementing "remaining_rotations" attribute) would allow my desired functionality without breaking any existing users who are inexplicably depending on the current behavior.
This is related to but I think does not duplicate #44
Code of Conduct
[X] I agree to follow this project's Code of Conduct
Terraform CLI and Provider Versions
Terraform Configuration
Expected Behavior
Once the fixed expiration date has passed, I expect the basis time to be updated, indicating that the rotation does not need to happen again.
Actual Behavior
Upon passing the expiration date, the basis time is updated as expected. However, rotations continue to happen repeatedly on all subsequent applies. I haven't looked at the code, but presumably this is because the comparison is against the current time / plan time instead of the resource basis time / ID.
Steps to Reproduce
How much impact is this issue causing?
Medium
Logs
No response
Additional Information
The documentation does somewhat indicate that "When the current time has passed the rotation timestamp, the resource will trigger recreation", but it's not entirely clear if that means "every single apply". I mean, that's definitely what happens, but it seems that a singular rotation is what's expected by reading "This prevents perpetual differences" in the documentation. So either the documentation should be updated with a warning that setting
[rotation_rfc3339](https://registry.terraform.io/providers/hashicorp/time/latest/docs/resources/rotating#rotation_rfc3339)
in the past will cause perpetual differences, or the code should be updated to only trigger a single rotation upon passing the fixed rotation date.I suppose adding a parameter like "rotate_once" with a default of false (or a "rotation_count" with a default like -1 to communicate infinite rotations, and a decrementing "remaining_rotations" attribute) would allow my desired functionality without breaking any existing users who are inexplicably depending on the current behavior.
This is related to but I think does not duplicate #44
Code of Conduct