Terraform VMware Cloud Director Provider v3.10.0 is available now, introducing many new features and improvements.
Introducing a new guide to deploy Kubernetes clusters using Container Service Extension (CSE) v4.0
This new version of the provider adds a new CSE guide that explains, step by step, how to deploy a Tanzu Kubernetes Grid Multi-cloud (TKGm) cluster by using the already existing RDE capabilities that were introduced in the previous v3.9.0 release.
The new guide comes with a set of configuration files that can be used as a starting point, showing a real example of creating a TKGm cluster in VCD.
The Container Service Extension v4.0 installation guide has also been upgraded to make use of
the new UI Plugin resource, that will allow administrators to fully automate their setup by installing
the “Kubernetes Container Clusters UI plug-in v4.0”, for their tenant users who are not familiar with Terraform to be able to create TKGm clusters using the UI wizard.
Extending the Runtime Defined Entity framework with new capabilities
A new set of resources and data sources will allow administrators to define and manage Behaviors in their existing Defined Interfaces and override them in their Defined Entity Types:
Users can also programmatically invoke Behaviors in their RDEs with the new released version v2.21.0 of the go-vcloud-director SDK.
IP Space management
Users of VCD versions 10.4.1+ can now use IP Spaces for their IP addressing needs. This functionality is supported in terraform-provider-vcd with 4 new resources and their corresponding data sources:
Such an abundance of new resource to use a recently introduced functionality called for a dedicated guide page that explains the relationship between new and old resources, and has a complete usage example.
Service account and API token management
The new version of the provider supports the creation and management of Service Accounts and API tokens.
The new Service Account resource is designed to make it easier to control service interaction with
your VCD environment. You can manage the lifecycle of service accounts directly within the provider. This facilitates granular permissions management, allowing you to define the exact scope of access for each service, reducing security risks and promoting more efficient operations.
Similarly, the new API Token resource allows you to automate creating, renewing, and revoking API tokens. This makes it straightforward to manage the access of applications and services to your VCD environment.
Distributed firewall management improvements
By popular demand, we have added a new resource (and data source) vcd_nsxt_distributed_firewall_rule that adds the capability of managing firewall rules one by one as opposed to already existing vcd_nsxt_distributed_firewall that handles all firewall rules in one resource. Additionally, vcd_vdc_group, has a new field remove_default_firewall_rule that helps to clean up the default firewall rule.
Improved IPv6 support
IPv6 configurations are now validated by adding a layer of automated tests and improved
IPv6 support in the following way:
Provider VDC resource
The new resource vcd_provider_vdc allows users with system administrator privileges to create and manage a provider VDC. Two auxiliary data sources were introduced to facilitate the creation of a provider VDC: vcd_resource_pool and
SAML configuration for organizations
System administrators can set and modify SAML configuration for a specific organization using vcd_org_saml. To help set up the SAML service, a companion data source (vcd_org_saml_metadata) allows users to get the organization’s (service provider) SAML metadata, which will then be passed to the identity provider. Once the administrators get the identity provider metadata, they can use such a file to set the service.
Cloned vApp operations
vcd_cloned_vapp is a resource that creates vApps from either a vApp template or another vApp. This resource should be used only on creation, although deletion also works. The result of using this resource is a regular vApp (vcd_vapp), with all its contents derived by either a vApp template or another vApp. As of this first implementation, no configuration is available: the vApp is simply cloned from the source vApp template or vApp.
In certain situations, Terraform users may require ignoring specific metadata entries added by a 3rd party to a given resource. This new version of the provider adds a new experimental feature that will allow ignoring the metadata entries configured in the provider block. For example:
This setup will make the provider ignore all metadata entries set in Organizations named “client1” and which key is “environment”.
This feature includes a mechanism to avoid ignoring metadata entries that were set by Terraform itself, providing users better control of what they are configuring and better feedback.
There are more full features and enhancements, which you can see in the project changes log.
And, as always, we are awaiting your feedback and suggestions on GitHub Issues and #vcd-terraform-dev Slack channel (vmwarecode.slack.com).