Invalid value for module argument

Hello,

In one module (called module1) I have this code:

data "openstack_networking_port_v2" "public_subnet_dhcp_ports" {
  depends_on   = [openstack_networking_subnet_v2.public_subnet]
  count        = var.network_internal ? 0 : 1
  network_id   = openstack_networking_network_v2.public_network[count.index].id
  device_owner = "network:dhcp"
}

// All outputs about dhcp ports for internal subnet
output "dhcp_ports" {
  value       = data.openstack_networking_port_v2.subnet_dhcp_ports
  description = "Output of object openstack_networking_port_v2 filtered for DHPC for internal subnet"
}

In another module (called module2), I have this code:

variable "dhcp_ports" {
  type        = list(string)
  description = "List of DHCP ports used by OpenStack"
}

resource "netbox_ipam_ip_addresses" "netbox_dhcp_ips" {
  for_each    = var.dhcp_ports
  address     = format("%s/24", each.value.all_fixed_ips[0])
  description = "IP used by internal OpenStack DHCP"
  tenant_id   = var.netbox_tenant_id
  tags        = var.tags
  status      = "active"
}

When I called the module2 with info from the module1, I used this:

dhcp_ports       = tolist(module.tenant_infra-test_internal_01.dhcp_ports.*.all_fixed_ips)

During the execution, I have this error:

Error: Invalid value for module argument
  on infra-test.tf line 103, in module "tenant_infra-test_reserved_ips_internal_01":
 103:   dhcp_ports       = tolist(module.tenant_infra-test_internal_01.dhcp_ports.*.all_fixed_ips)
The given value is not suitable for child module variable "dhcp_ports" defined
at
.terraform/modules/tenant_infra-test_reserved_ips_internal_01/variables.tf:18,1-22:
incorrect list element type: string required.

What’s wrong ?

I replaced the type from list(string) to list.
Now I have this message:

The given "for_each" argument value is unsuitable: the "for_each" argument
must be a map, or set of strings, and you have provided a value of type list
of list of string.
``

The error message here indicates that you have a list of list of strings, which makes sense to me:

  • The input variable is set to dhcp_ports.*.all_fixed_ips, i.e. a list of the all_fixed_ips values for all resources
  • The all_fixed_ips attribute of an openstack_networking_port_v2 is a list(string)

Since you are using count to conditionally create the resource, instead you may want to write dhcp_ports[0].all_fixed_ips. This will return a single list(string), which should match your module’s (correct) original input variable type requirement.

I changed the module2 with:

variable "dhcp_ports" {
  type        = list
  description = "List of DHCP ports used by OpenStack"
}

resource "netbox_ipam_ip_addresses" "netbox_dhcp_ips" {
  count       = length(var.dhcp_ports)
  address     = format("%s/24", var.dhcp_ports[count.index])
  description = "IP used by internal OpenStack DHCP"
  tenant_id   = var.netbox_tenant_id
  tags        = var.tags
  status      = "active"
}

Now I have this error:

Error: More than one openstack_networking_port_v2 found (3)
  on .terraform/modules/.../main.tf line 70, in data "openstack_networking_port_v2" "subnet_dhcp_ports":
  70: data "openstack_networking_port_v2" "subnet_dhcp_ports" {

The data openstack_networking_port_v2 in module1 will find several dhcp ports which is normal.
I would like to get this list of openstack_networking_port_v2 objects.
For each of them I would like to extract the all_fixed_ips which is a list of string (IP).

How to accomplish this ?

Need more help on this topic please.

Hi @smutel,

Your new question seems to be about the behavior of the OpenStack provider in particular, rather than about Terraform in general, so unfortunately fewer people in this particular category are familiar with it.

It might help to start a new topic in the Terraform Providers forum category. Unfortunately I don’t think the OpenStack provider is as commonly used as some others so I can’t be certain that there will be other folks familiar with that provider watching that category, but I think it’s still more likely to be seen there (with an appropriate new subject line describing the new problem) than as a follow-up to a general question about the Terraform language.