vra deployment cloudconfig: Inappropriate value for attribute "resources": set of object required.

[gthieleb]

Code of Conduct

This project has a Code of Conduct that all participants are expected to understand and follow:

• I have read and agree to the project's Code of Conduct

vRA Version

Version 8.11.2.30052 (21452955)

Terraform Version

Terraform v1.4.0
on linux_amd64

vRA Terraform Provider Version

• provider registry.terraform.io/hashicorp/random v3.5.1
• provider registry.terraform.io/vmware/vra v0.7.2

Affected Resource(s)

vra_deployment

Terraform Configuration Files

resource "vra_deployment" "this" {
  name        = var.deployment_name != "" ? var.deployment_name : "deployment-${random_pet.deployment_sfx.id}"
  description = "terraform deployment"

  catalog_item_id      = data.vra_catalog_item.this.id
  project_id           = data.vra_project.this.id

  inputs = {
    environment = "vra"
    vmCount = 1
    ram = 4
    cpuCount = 4
    disks = jsonencode([5, 10])
    backup   = true
    password = local.password
    sshkey = local.sshkey
    nic0 = "private"
    nic1 = "nouplink"
    nic2 = "nouplink"
  }

  resources = {
    vSphere_VM =  {
      properties = {
        cloudConfig = {}
      }
    }
  }

  timeouts {
    create = "30m"
    delete = "30m"
    update = "30m"
  }

  lifecycle {
    ignore_changes = [
      inputs
    ]

  }
}

Expected Behavior

The deployment (Ubuntu/SLES) should be deployed with a custom cloud init configuration.

An example yaml used in vRA deployment blueprint:

resources:
  vSphere_VM:
    properties:
      cloudConfig: |
        users:
          - default
          - name: ${input.username}
            lock_passwd: false
            sudo: ['ALL=(ALL) NOPASSWD:ALL']
            groups: [wheel, sudo, admin, docker]
            shell: '/bin/bash'
            ssh_authorized_keys:
              - ${input.sshkey}

Actual Behavior

│ Error: Incorrect attribute value type
│
│   on main.tf line 58, in resource "vra_deployment" "this":
│   58:   resources = {
│   59:     vSphere_VM =  {
│   60:       properties = {
│   61:         cloudConfig: {}
│   62:       }
│   63:     }
│   64:   }
│
│ Inappropriate value for attribute "resources": set of object required.

Steps to Reproduce

1. terraform apply

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[an2ane]

Are you trying to run a 2nd custom cloudinit config?
By looking at the code, it seems that the resources input is "read only".

[gthieleb]

@an2ane yes, the deployment of the Linux VM ships already with a cloudconfig. I want to inject additional cloudconfig commands. What property should i use instead of the resource property?

[gthieleb]

@an2ane Hi do you have any idea how to inject cloudinit Code? I recently discovered the 'blueprint_content' property [1]. This has the side effect that one needs to inject the whole blueprint instead of only the cloudinit part.

[1] https://registry.terraform.io/providers/vmware/vra/latest/docs/resources/vra_deployment#blueprint_content

[an2ane]

@gthieleb No, this is a work I have to do as well on my side. I know you can have 3 kind of cloud init.

1. The cloud init already inside your vm template
2. The cloud init attached to the image mapping
3. The cloud init inside the cloud template.

On my side, I don't use the 2. Our OS team have theirs, which I don't change. And I have my own inside the cloud template.

Two ways I was thinking about, are:

1. Let the user have access to the cloud template cloudinit config, and if they screw it, then the fault is theirs.
2. Have multiple inputs in the cloud template (like users, runcmd, ...) and concatenate them to the cloudinit config.

Either way, not the greatest solution.

Hope it could help.

[gthieleb]

@an2ane thanks for your suggestions. I tend to using 1. as I think I have access to the cloud template and using the catalog blue print datasource [2] as an input.

[2] https://registry.terraform.io/providers/vmware/vra/latest/docs/data-sources/vra_catalog_source_blueprint#config

[gthieleb]

@an2ane It seems I need some permissions to access the catalog source blueprint. Currently I do not have access.