Terraform VMware Cloud Director Provider v3.14.0

Terraform VMware Cloud Director (VCD) Provider v3.14.0 is available now, and it supports VCD versions from 10.4.0 to 10.6.0. This release delivers features and improvements actively requested by the users. It contains 5 new resources and 7 new data sources, 11 improvements and 9 bugfixes.

API Filters and External Endpoints

API Filters allow to extend VCD API with customised URLs that can be redirected to an External Endpoint. These two concepts have now their respective resources in the Terraform provider:

Here’s an example that shows how to use them:

resource “vcd_external_endpoint” “ep1” {
vendor = “broadcom”
name = “my-endpoint”
version = “1.0.0”
enabled = true
description = “A simple external endpoint example”
root_url = “https://10.1.1.1/my-service”
}

resource “vcd_api_filter” “af” {
external_endpoint_id = vcd_external_endpoint.ep1.id
url_matcher_pattern = “/my-service/.*”
url_matcher_scope = “EXT_API”
}

When this configuration is applied, all requests that are made to <vcd-url>/ext-api/my-service/... will be redirected to https://10.1.1.1/my-service with all the request contents and query parameters coming from VCD.

ALB Virtual Service Policies

Three new resources and data sources for managing ALB Virtual Service HTTP Policies. These resources can become quite big due to the amount of match criteria and action configuration, but one can find examples in each of their own documentation pages:

vcd_nsxt_alb_virtual_service_http_req_rules for managing HTTP Request Rules
vcd_nsxt_alb_virtual_service_http_resp_rules for managing HTTP Response Rules
vcd_nsxt_alb_virtual_service_http_sec_rules for managing HTTP Security Rules

Improvements

Improved user experience with RDE Behaviors

The resources and data sources vcd_rde_interface_behavior and vcd_rde_type_behavior had the execution argument, which only supported key-value mappings to define behavior executions. This release adds a new argument, execution_json, that allows to define more complex behavior executions by providing a complex JSON string with the specification:

resource “vcd_rde_interface_behavior” “behavior” {
rde_interface_id = vcd_rde_interface.my_interface.id
name = “MyBehavior”

# ‘execution_json’ allows to use complex structures that are not possible with a regular
# ‘execution’ map, like a nested “execution_properties” in a webhook behavior:
execution_json = jsonencode({
“type” : “WebHook”,
“id” : “testWebHook”,
“href” : “https://hooks.slack.com:443/services/T07UZFN0N/B01EW5NC42D/rfjhHCGIwzuzQFrpPZiuLkIX”,
“_internal_key” : “secretKey”,
“execution_properties” : {
“template” : {
“content” : “<template_content_string>”
},
“_secure_token” : “secureToken”,
“invocation_timeout” : 7
}
})
}

Note that the argument execution can still be used for simpler definitions. Also, the vcd_rde_behavior_invocation data source allows to use JSON arguments as well:

data “vcd_rde_behavior_invocation” “invoke” {
rde_id = vcd_rde.rde.id
behavior_id = vcd_rde_interface_behavior.behavior.id
invoke_on_refresh = true
arguments_json = jsonencode({
“template” : {
“content” : “hello world”
},
“_secure_token” : “secureToken”,
“invocation_timeout” : 7
})
}

New data source for Catalog access controls

With the new vcd_catalog_access_control data source, one can read Catalog access controls, and all the information it provides in its attributes (like the Organisations which the Catalog is shared with).