8.8.0 Release Notes

Terraform is currently available as a technology preview for early adopters.

You can now view and manage any type of resource deployed by Terraform. Discovery of existing deployments allows easy adoption at any level of maturity and provides single pane of glass visibility without requiring changes to any existing deployment methodologies. Commander’s powerful governance capabilities can be leveraged to manage Terraform deployments from beginning to end.

From the Admin Portal, you can access the state of Terraform configurations stored in backends for Terraform Cloud, AWS S3 buckets, and Azure Blob Storage containers. This allows you to view details such as the outputs, variables, and resources for your Terraform deployments.

Similar to CloudFormation and ARM templates, you can also make Terraform configurations available in the service catalog. Snow Software provides workflow plug-ins to provision and decommission Terraform configurations. Change requests allow Day-2 operations against any type of resource deployed by Terraform.

For more information, see Terraform.

For highly available deployments, the Terraform service must be manually configured on the passive node.

For more information on the technology preview or to provide feedback, contact support through the Snow Support Portal.

Change requests on XaaS resources

If you deploy resources through Terraform, AWS stacks, GCP deployments, or Azure Resource Groups, you can now create change requests with custom workflows that can be used to make Day-2 configuration changes against any type of resource that may exist within your hybrid cloud.

For example, you could create a change request to add requesters to the access list of an AWS S3 bucket or an Azure Blob Storage container. For more information, see Request changes to XaaS resources.

You can use variables in workflows associated with these change requests to access Commander metadata and allow the workflows to integrate with XaaS Resources. For example, you can insert variables in workflow emails or pass variables to workflow scripts.

Many of the existing approval and completion workflow variables offered by Commander can now be used. Commander also now provides a #{target.context} variable, which returns the identifying resource name and type for XaaS resources. This allows dynamic form elements and workflows to know the resource that they're operating on. For more information, see Workflow variables.

Formless change requests

When you create a change request, you can now configure whether you want to present a form to users after they select the change request.

Providing change requests without forms can simplify the change request process. For example, consider a change request clearly named "Decommission VM" — a user could select this change request to decommission a VM that's no longer required. No further input or explanation is necessary, so an extra form isn't required.

This allows change requests to be used in a similar manner to command workflows, with the added benefits that they can be subject to approval and can be run against XaaS resources. For more information, see Create Change Requests.

To help further integrations and automation, these new features are introduced in the Commander REST API.

• Terraform support has been added, enabling resources deployed through Terraform to now be accessible through the API. Commander can access the state stored in backends for Terraform Cloud, AWS S3 buckets, and Azure Blob Storage containers. In addition, details like the outputs and resources are available through Commander. The endpoints are:

  • POST|GET /terraform-accounts
  • GET|PATCH|DELETE /terraform-accounts/{id}
  • POST /terraform-accounts/{id}/synchronize
  • GET /terraform-workspaces
  • GET /terraform-workspaces/{id}
  • POST /terraform-workspaces/{id}/synchronize
  • GET /terraform-workspaces/{id}/outputs
  • GET /terraform-workspaces/{id}/environment-variables
  • GET /terraform-workspaces/{id}/terraform-variables
  • GET /terraform-workspaces/{id}/state

• Credentials can now be browsed and filtered. In addition, the API now supports all types of credentials that are stored in Commander: RSA, password, and keypair. This allows superusers to retrieve credentials that are stored in Commander, so they can be used in scripts run by Commander. For example, credentials may be required to perform operations on Terraform resources or to create and update Tagged VMs in NSX. The endpoints are:

  • GET /credentials
  • GET /credentials/{name}

For an overview of the REST API, see Get Started with the Commander REST API. To browse the API reference, see Commander API (v3).

• All reports which show costs can be generated in any currency that the European Central Bank supports, as appropriate for the person that will consume the report.
• Service Portal users can now select a language for the Service Portal. Administrators can control which languages are available for Service Portal users to select.