vApp properties of type 'boolean' behave counter-intuitive

[djpbessems]

Terraform Version

0.15.0

vSphere Provider Version

v1.26.0

Affected Resource(s)

• vsphere_virtual_machine

Terraform Configuration Files

resource "vsphere_virtual_machine" "vm" {
  [...]
  vapp {
    properties = {
      # 1-4 do not work
      "guestinfo.boolean1" = true
      "guestinfo.boolean2" = false
      "guestinfo.boolean3" = "true"
      "guestinfo.boolean4" = "false"
      # 5-6 do work
      "guestinfo.boolean5" = "True"
      "guestinfo.boolean6" = "False"
    }
  }
}

Debug Output

n/a

Panic Output

n/a

Expected Behavior

All formats in the supplied code result in a vApp property being set to the corresponding boolean value.

Actual Behavior

The following error is returned:

Error: error while applying vapp config Invalid value 'true' specified for property guestinfo.boolean1.

I guess not many people have had a need yet to use vApp properties of a type other than string or int, but boolean type right now only works correctly when you use a capitalized string True/False for its value.

Steps to Reproduce

1. terraform apply

Important Factoids

Tested on a vCenter v6.7

References

n/a

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

[tenthirtyam]

@djpbessems -

In Terraform a bool is true or false.

Example: Variable for the Terraform provider for VMware vSphere configuration.

variable "vsphere_insecure" {
  type        = bool
  description = "Allow insecure connections. Set to `true` for self-signed certificates."
  default     = false
}

However, for OVF properties, even though the type is booleen, the vApp Options only accept the values of "True" or "False". In these instances, it's recommended to define the variable as a string in the Terraform plan and pass the value in the correct title case.

Example: Variable for Terraform provider for VMware vSphere to pass as an OVF property to an OVA.

variable "appliance_ssh_enabled" {
  type        = string
  description = "Enable SSH on the virtual appliance. One of `True` or `False`."
  default     = "True"
}

NOTE: You won't be able to get crafty declare it as bool in Terraform and then attempt to convert it to a title case string using title(format("%s", var.appliance_ssh_enabled)) as Go is strongly typed.

Hope this helps,
Ryan
@tenthirtyam

Recommend: close/not-a-bug

[djpbessems]

I agree this does not necessarily needs to be treated as a bug, but I think a clear warning would need to be added in the documentation then.

[tenthirtyam]

@djpbessems - Can you update the label to documentation? If so, I'll update this in an documentation update that I'm currently addressing.

Ryan

Recommend: label/documentation

[djpbessems]

I'm afraid I cannot; I am not a contributor.

[tenthirtyam]

No worries, I'll work on addressing it with the PM.

Ryan

[tenthirtyam]

@djpbessems -

Does the above help to answer your questions on passing the bool vApp properties?

I've addressed the documentation gap in #1513 which is pending review and merge.

Ryan

[djpbessems]

Well I already knew how to use the boolean properties; I created the ticket because the current behaviour is counter intuitive, even if documentation is in place. And in all honesty, while your proposed PR does mention the way to deal with booleans, it is not easily found when looking up documentation on vApp properties and will be overlooked almost certainly by end-users.

So to answer your question, no it does not help answering my questions, but that wasn't the point of me creating the ticket; instead I would suggest adapting the behaviour so that the provider accepts all variants I listed and translates appropiately.

But that's all I can do, suggest change; if the maintainers of this repo decide otherwise, so be it.

Maybe worth adding; I don't see this as a fault of Terraform or this TF provider, but lacking implementation of the OVF specification on VMware's part.

[tenthirtyam]

Thanks for the response @djpbessems. Please note that to date, the reference pull request for the docs update is not yet merged by the maintainers.

Ryan

[tenthirtyam]

cc @iBrandyJackson and @appilon for review and next steps.

[appilon]

While I agree it will be common for new users to trip up here, this is a problem common to all providers that allow for passing map data directly to the vendor, they have to maintain a mental model in their mind of Terraform/Golang's type system and recognize when they aren't working with it anymore (in this case they are defining a map[string]string and passing it to vsphere)

Unfortunately Terraform maps must remain homogenous (can't have mixed types) So this map in question likely needs to remain a map[string]string to support all possible key/value pairs (so we could not make it map[string]bool and serialize to vsphere's capital-case "True", "False").

Oddly enough @tenthirtyam I did try the crafty workaround in terraform console and it did work? at least it did locally for me in terraform v1.1.3

➜ terraform console
> title(format("%s", true))
"True"

With all that said, this issue will be closed once the documentation updates are merged.

[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.