« Back to Index

Fastly: Terraform 1.0.0 Migration Guide

View original Gist on GitHub

Tags: #delete #fastly #work

Fastly Terraform 1.0.0 Migration Guide.md

Migration Guide

Resources omit _v1 suffix:

All resources now have a consistent naming convention which omit the previous v1 suffix.

Logging resources have consistent naming format:

All logging resources now have a consistent naming convention with the provider prefixed with logging_.

Director capacity removed:

The Fastly API never supported the capacity field for a director resource (this was added to the Terraform provider by mistake). Load balancing of director backends is managed by the weight field on each associated backend resource.

GCS Logging field email renamed:

The Fastly API was updated with a new user field to replace email.

Logging format and format_version defaults changed:

Pre-1.0.0 the default values for format and format_version were incorrectly set to an older version 1. All new logging endpoints use the version 2 custom log format by default.

Backend auto_loadbalance default changed:

The Fastly web interface defaults “Auto load balance” to “No”. The most common reason for having multiple backends in a single service is to route different paths to different backends, rather than load balance between different origins. The provider pre-1.0.0 defaulted auto_loadbalance to true, which was considered unexpected behaviour. The default is now false.

Gzip content_types and extensions type changed:

The content_types and extensions fields for a gzip resource, pre-1.0.0, were implemented as a TypeSet (an unordered collection of items whose state index is calculated by the hash of the attributes of the set). This would result in confusing and unexpected diffs. Now they are implemented as a TypeList (an ordered collection of items).

Automatically opt-in to ignore_changes behaviour for versionless resources:

The versionless resources (ACL entries, Dictionary items and Dynamic VCL Snippets) are sometimes used in a way whereby they are “seeded” via Terraform and then updated/managed externally via the API or UI console. For this, the documentation suggests using ignore_changes, a built-in Terraform meta-argument, that allows the user to specify fields to ignore and from which to allow the state to drift.

However, sometimes this isn’t obvious or the user doesn’t understand this suggestion until it is too late, and data ends up getting lost. This happens because the user makes changes elsewhere and doesn’t use ignore_changes, so Terraform takes action to remove the state drift and deletes their changes. This data is then unrecoverable.

In 1.0.0 the default behaviour of these resources has changed. Terraform now ignores any changes, and only allows the “dangerous” behaviour by explicitly opting in with a manage_* option (e.g. manage_entries, manage_items, manage_snippets depending on the versionless resource).