Add support for dynamic block on resource "cml2_node"

[tiagosil-cisco]

It would be good to have the option of using dynamic blocks on "cml2_nodes" as we could differ basic config depending on nodedefinition, for example.

Something similar to below

resource "cml2_node" "nodes" {
  for_each       = { for key, value in local.nodes : key => value if value.nodedefinition == "iosxrv9000" || value.nodedefinition == "cat8000v" }
  lab_id         = cml2_lab.lab.id
  label          = each.value.hostname
  nodedefinition = each.value.nodedefinition
  tags           = each.value.tags
  x              = each.value.x
  y              = each.value.y

  dynamic "configuration" {
    for_each = each.value.nodedefinition == "iosxrv9000" ? [1] : []
    content {
      configuration = <<-EOT
      // XR base config
      EOT
    }
  }

  dynamic "configuration" {
    for_each = each.value.nodedefinition == "cat8000v" ? [1] : []
    content {
      configuration = <<-EOT
      // XE base config
      EOT
    }
  }
}

[rschmied]

I haven't tried this, yet. But "dynamic" is a HCL construct -- so, wouldn't this work already? What would be required on the CML TF provider to make this work?

Also note that the way configurations are provisioned with 2.7 forward allows for multiple configuration files. Basically, the configuration schema allows now either a string or a map, where the key is the filename and the value is the content of the filename. How would that be handled with this "dynamic configuration"?

[rschmied]

based on this https://blog.boltops.com/2020/10/05/terraform-hcl-loops-with-dynamic-block/ and also on the new schema for node configurations:

configurations	[
List of node configuration file objects.
{
name*	string
minLength: 1
maxLength: 64
The name of the configuration file. Can also use the keyword "Main" to denote the main configuration file for the given definition.

content	string
nullable: true
Node configuration (no more than 20MB).
}]

I think this will be doable when I update the node resource to accept a list of configurations in addition to a single configuration.

[rschmied]

@tiagosil-cisco after implementing named configurations and playing with this for a bit it seems like this isn't exactly possible... Named configurations are not "blocks" but a list of configurations. Therefore, the dynamic keyword does not apply... One can, however, build something like show below. It would also be possible to have the "baseconfigs" map use the node definition as key and the choose the proper entry per node.

I think it would also be possible to merge a base config (on node definition) and a node config (in a separate list). But all of this does NOT use dynamic blocks as there's "configuration block" as part of a node.

# Define nodes

locals {
  nodes = [
    {
      hostname       = "host1"
      nodedefinition = "ubuntu"
      tags           = toset(["nodes", "bla"])
      x              = 0
      y              = 100
    },
    {
      hostname       = "host2"
      nodedefinition = "ubuntu"
      tags           = toset(["nodes", "bla"])
      x              = 0
      y              = 100
    },
    {
      hostname       = "host3"
      nodedefinition = "ubuntu"
      tags           = toset(["nodes", "bla"])
      x              = 0
      y              = 100
    },
  ]
  configs = {
    "host1" = [{
      name    = "user-data"
      content = "hostname host1"
    }]
    "host2" = [{
      name    = "user-data"
      content = "hostname host2"
    }]
    "host3" = [{
      name    = "user-data"
      content = "hostname host3"
    }]
  }
}

resource "cml2_node" "node" {
  for_each       = { for key, value in local.nodes : key => value if value.nodedefinition == "ubuntu" }
  lab_id         = cml2_lab.lab.id
  label          = each.value.hostname
  nodedefinition = each.value.nodedefinition
  tags           = each.value.tags
  x              = each.value.x
  y              = each.value.y
  configurations = local.configs[each.value.hostname]
}

[rschmied]

Fixed by PR #130.

Keeping the nested attribute over the block even though that only blocks allow to use dynamic. configuration. Apparently, with the framework nested attributes are preferred and the desired result can be achieved there as well. Dynamic blocks were only needed because they were NOT nested attributes (afaict).

Prefer NestedAttribute over Block. Blocks should typically be used for configuration compatibility with previously existing schemas from an older Terraform Plugin SDK. Efforts should be made to convert from Block to NestedAttribute as a breaking change for practitioners.

https://pkg.go.dev/github.com/hashicorp/terraform-plugin-framework/provider/schema