v1.7.10 broke local references

[DavidCPorter]

Overview of the Issue

I believe these changes broke references in my locals block from version 1.7.9 -> 1.7.10
https://github.com/hashicorp/packer/pull/11527/files

## 
# main.pkr.hcl
...

locals {
  vms_to_build = var.gitlab_vms_to_build
  _vm_groups = var.__vm_groups
  _rhel7     = merge(local._vm_groups, var.__rhel7)
  _rhel7_9   = merge(local._rhel7, var.__rhel7_9)
  _rhel8 = merge(local._vm_groups, var.__rhel8)
  _windows = merge(local._vm_groups, var.__windows)
  example-grp_alt_rhel79 = merge(local._rhel7_9, var.__example-grp_alt_rhel79)
  dynamic_map = { for vm in local.vms_to_build : vm => lookup(local, vm, "VM NAME NOT FOUND") }
}

# virtualbox-iso source
source "virtualbox-iso" "template" {
}


#####################################
# DYNAMIC BUILD SECTION ############
#####################################

build {
  dynamic "source" {
    for_each = local.dynamic_map
    labels   = ["source.virtualbox-iso.template"]
    content {
      # this name attribute is required for dynamic sources
      name             = source.key
      vm_name          = source.key
      output_directory = source.value.output_directory
...
}

error

specifically, this line

dynamic_map = { for vm in local.vms_to_build : vm => lookup(local, vm, "VM NAME NOT FOUND") }

produces a map with { vm => "VM NAME NOT FOUND" } in 1.7.10
map should be { vm => local.vm } as it was in 1.7.9

Bottom line... I'm not able to find locals in a locals lookup e.g. lookup(local, "vm name", default)

[nywilken]

Hi @DavidCPorter thanks for reporting. I was able to reproduce using 1.7.10. Interesting enough the results would sometimes vary in the lookup not being able to find the key and sometimes work without issue. In Packer 1.7.9 I got the same results each time. This looks like a regression so I will label it and work to address it for the next release.

Do you find the results change if you run Packer multiple times?

For the sake of the test I tried passing in a list of different values to the vms_to_build var on the CLI. Please let me know if you are doing something different.

~>  noglob packer console -var 'vms_to_build=["amgroup","rhgroup","_onemore","ubgroup"]' /tmp/example.pkr.hcl
> variables
> > input-variables:

var.vms_to_build: "[\n  \"amgroup\",\n  \"rhgroup\",\n  \"_onemore\",\n  \"ubgroup\",\n]"

> local-variables:

local._onemore: "onemorelocal"
local.amgroup: "barfoo"
local.dmap: "{\n  \"_onemore\" = \"onemorelocal\"\n  \"amgroup\" = \"barfoo\"\n  \"rhgroup\" = \"foo\"\n  \"ubgroup\" = \"bar\"\n}"
local.rhgroup: "foo"
local.ubgroup: "bar"
local.vms_to_build: "[\n  \"amgroup\",\n  \"rhgroup\",\n  \"_onemore\",\n  \"ubgroup\",\n]"

> ^C


~>  noglob packer console -var 'vms_to_build=["amgroup","rhgroup","_onemore","ubgroup"]' /tmp/example.pkr.hcl
> variables
> > input-variables:

var.vms_to_build: "[\n  \"amgroup\",\n  \"rhgroup\",\n  \"_onemore\",\n  \"ubgroup\",\n]"

> local-variables:

local._onemore: "onemorelocal"
local.amgroup: "barfoo"
local.dmap: "{\n  \"_onemore\" = \"onemorelocal\"\n  \"amgroup\" = \"barfoo\"\n  \"rhgroup\" = \"foo\"\n  \"ubgroup\" = \"NOT FOUND\"\n}"
local.rhgroup: "foo"
local.ubgroup: "bar"
local.vms_to_build: "[\n  \"amgroup\",\n  \"rhgroup\",\n  \"_onemore\",\n  \"ubgroup\",\n]"

[DavidCPorter]

Yes, vms_to_build is passed on the command line and each value points to a key in the local object. In my implementation, each value will always point to a defined local map object. Your test case is indeed a good representation of my implementation.

I ran the build several times with 1.7.10 and each time the local map object was not found. However, using the -debug flag runs the build successfully in 1.7.10.

It's probably worth noting that, along with vms_to_build, I'm passing in all the var references from the locals block from definition files "pkvars" from the command line e.g. var-file=example.pkvars.hcl. Each of these are declared in the main file above the locals block.

[github-actions]

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.