HashiCorp Terraform vCloud Director Provider v2.5.0 version is here! With this new release we’re enabling cloud providers and their customers deliver more advanced automation with new data sources and import capabilities, which enable easy inclusion of existing vCD resources into Terraform management. We have also extended read functionality, which enables monitoring changes done to infrastructure, added a new kind of NAT and firewall resources for advanced security automation and various other improvements. Finally, this v2.5.0 release adds support for the latest vCloud Director 10.0 version. So, let’s take a deeper look at the key new capabilities.

New Data Sources

In this version we have added a raft of data sources. Data sources are really cool, as they allow you to query details about resources which have been created by means other than Terraform (like through UI) or by other users (if permissions allow, of course).

Here’s an example where we query an existing external network and use its IP address to create a DNAT rule:

Almost all resources have their corresponding data sources now! Here’s a full list. As you can see only VM is missing (which we’re adding to the next release):

• vcd_lb_service_monitor
• vcd_lb_server_pool
• vcd_lb_app_profile
• vcd_lb_app_rule
• vcd_lb_virtual_server
• vcd_nsxv_dnat
• vcd_nsxv_snat
• vcd_nsxv_firewall_rule
• vcd_org
• vcd_org_vdc
• vcd_catalog
• vcd_catalog_item
• vcd_catalog_media
• vcd_independent_disk
• vcd_external_network
• vcd_edgegateway
• vcd_network_routed
• vcd_network_isolated
• vcd_network_direct
• vcd_vapp

Reads for Resource Parameters

Together with data sources, we have added read functionality to most of the resources’ properties. These reads take place during a state refresh (say, when running terraform planor terraform apply). With these reads in place, Terraform “notices” changes which have been made to infrastructure without its knowledge.

For instance, if we go to UI and change the above DNAT rule’s translated_port from 443 to 1000 and run Terraform, we will get a notification about such discrepancy:

As a user you can now decide whether to:

a. Re-apply the value that is in HCL file to vCD (by answering “yes”).
b. Manually adjust the HCL file with the new read value from vCD and rerun the plan.

Migrate Existing Resources with Imports

We have also added import capabilities for migrating existing resources into Terraform management.

Say, we have a firewall rule in UI, but we don’t have it in Terraform configuration file yet:

With v2.5.0 we can import it into the state file, which will make it straightforward to write it up in the configuration for further management via Terraform.

First, let’s define a placeholder resource in the HCL file with the known field values filled in:

And let’s run a tailored terraform import command telling into which resource to import the above UI rule:

We now have this resource in the state file with all its imported values. Let’s run terraform plan which will show us the differences compared to contents in the HCL file.

Let’s copy/paste the relevant required values from the plan where it shows minuses to our configuration until terraform plan becomes “happy” and shows no differences.

If we run the plan again, it will report no changes, because values in the state and the HCL files match:

We can now make changes to this resource in Terraform configuration file and manage it as the usual Terraform resources!

For more general information about importing please see Terraform documentation.

New NSX-V DNAT, SNAT and Firewall Rules

You may have noticed that in the examples above the NAT and FW rule resources are different from the ones in previous versions. What we have done here is added new DNAT, SNAT and FW rule resources for Advanced Edge Gateways, which use NSX-V API (through a proxy in vCD API) as opposed to the older vCD API calls.

• vcd_nsxv_dnat
• vcd_nsxv_snat
• vcd_nsxv_firewall_rule

These new resources should always be used if your Edge Gateway is of Advanced (NSX-V) type.

Upgrade Note

Please note that in an effort to make the provider more robust, we have systematically changed resource identifiers in the state file to vCD IDs where names were used.

Here’s an example of a Catalog Item (please note the new long “urn:…” value in the “id” field):

When you upgrade from v2.4.0 to v2.5.0, in some cases this change may result in terraform plan asking to recreate a resource. In case this occurs, please see a new troubleshooting page where we describe how to use the import functionality to resolve it.

By the way, if you’d also like to learn more about the previous v2.4.0 release, please click here.

Other Improvements

Of course, as usual, we have added many other improvements and bug fixes too. Thank you for the community users who took time to publish issues hit and features needed – please keep the feedback coming!

Here are some of these items:

• Add support for vCD 10.0
• Drop support for vCD 8.20
• vcd_vapp – Add properties status and status_text
• vcd_vapp_vm – Allow to force guest customization
• vcd_vapp and vcd_vapp_vm– Support guest properties
• vcd_network_direct – Add computed properties (external network gateway, its netmask, DNS and DNS suffix)
• vcd_vapp_vm – New field computer_name
• vcd_independent_disk – Add computed properties (iops, owner_name, datastore_name, is_attached)
• vcd_catalog_media – Add computed properties (is_iso, owner_name, is_published, creation_date, size, status, storage_profile_name)

For a full list of additions and fixes, please see the v2.5.0 changelog.

And, most importantly, please give the new Terraform vCloud Director Provider a try! By the way, you can always reach us via GitHub or Slack #vcd-terraform-dev channel which you can join through VMware {code}.