terraform-provider-nomad: nomad_acl_token cannot unmarshal field ACLToken.ExpirationTTL with Nomad 1.5.x

Terraform Version

Terraform v1.3.9
on darwin_arm64
+ provider registry.terraform.io/hashicorp/nomad v1.4.19

Nomad Version

Nomad 1.5.0

Provider Configuration

provider "nomad" {}

Environment Variables

NOMAD_TOKEN=<redacted>
NOMAD_ADDR=http://127.0.0.1:4646"

Affected Resource(s)

  • nomad_acl_token

Terraform Configuration Files

resource "nomad_acl_token" "vault" {
  name = "Vault-management-token"
  type = "management"
}

Debug Output

│
│ Error: error creating ACL token: json: cannot unmarshal string into Go struct field ACLToken.ExpirationTTL of type time.Duration
│ 
│   with nomad_acl_token.vault,
│   on nomad_acl.tf line 1, in resource "nomad_acl_token" "vault":
│    1: resource "nomad_acl_token" "vault" {
│ 
│

Expected Behavior

naturally it should provision the resource

Actual Behavior

The error message is displayed and the apply fails.

Steps to Reproduce

  1. terraform init
  2. terraform apply

Important Factoids

ACLs are bootstrapped and the bootstrap token is set in the environment vars.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 13
  • Comments: 16 (4 by maintainers)

Commits related to this issue

Most upvoted comments

Hiya, any eta on this? The work around from @xkisu helps but is not ideal for use in our automated pipelines for configuring nomad.

Hey @jrasell I second above, can we please push out a release with a fix? This is hampering with CI flows for which it’s not easy to distribute a custom build of the provider.

In case anyone is looking for a patch in the meantime, make sure you’ve run terraform init in your project so the providers are cached in the project directory, and then modify the provider and build it like so:

$ git clone git@github.com:hashicorp/terraform-provider-nomad.git
$ cd terraform-provider-nomad

# Update the nomad dependencies
$ go get github.com/hashicorp/nomad
$ go get github.com/hashicorp/nomad/api

# Build the updated provider
$ go build -o terraform-provider-nomad

# Copy the updated provider to the local providers cache.
#
# On Linux or Windows this will be slightly different, check the existing path to see where it should go!
$ mv terraform-provider-nomad <your project dir>/.terraform/providers/registry.terraform.io/hashicorp/nomad/1.4.19/darwin_arm64/terraform-provider-nomad_v1.4.19_x5

You may need to delete the hashes section from terraform.tfstate for the registry.terraform.io/hashicorp/nomad provider since the checksums won’t match the modified provider.

Just to add to the report: terraform plan on state with existing resource does throw error as well:

Error: error checking for ACL token "<redacted>": &json.UnmarshalTypeError{Value:"string", Type:(*reflect.rtype)(0x101c343a0), Offset:19, Struct:"ACLToken", Field:"ExpirationTTL"}

Same Terraform & nomad provider versions as above. Nomad cluster in version 1.4.5.

Same for both type = "client" and type = "management".

Thanks!

Hi all, the release is now available as v1.4.20: https://releases.hashicorp.com/terraform-provider-nomad/1.4.20/. Thanks for your patience.

Hi @kochen it’s been open since Jan because I worked on it while also working on the SSO feature within the main Nomad repository. 1.5.0 has also only been GA for one week which includes that fix. We have a single remaining question on the PR before we will be able to merge it. If this takes longer than expected, then we will totally use a separate PR for just updating the dependency.

I people are willing to build from main, I can update the dependency in main. Due to the release process, however, we would wait to perform an official release until all items we have lined up are merged.

@jrasell Hi, any estimation for the next release date (I saw that https://github.com/hashicorp/terraform-provider-nomad/pull/305 has been merged)?

Just to know if we switch to a fork meanwhile or if we can wait. (We’ve just updated to Nomad 1.5 and the provider became unusable because of this bug)

Hi @wasilak, no concrete dates, but near-term.

@jrasell the PR you mentioned is opened since Jan 2023 and still in draft. If the solution is a simple provider update, wouldn’t it make more since to “just” update the provide to solve this, and not have to wait for the other PR?