1.0.0 (February 8, 2022)
ENHANCEMENTS:
- Changes for v1.0.0 #534
BUG FIXES:
Migration Guide
Resources omit _v1 suffix:
All resources now have a consistent naming convention which omit the previous v1 suffix.
fastly_service_v1->fastly_service_vcl(renamed with_vclsuffix)fastly_service_acl_entries_v1->fastly_service_acl_entriesfastly_service_dictionary_items_v1->fastly_service_dictionary_itemsfastly_service_dynamic_snippet_content_v1->fastly_service_dynamic_snippet_contentfastly_user_v1->fastly_user
When switching to the new 1.0.0 release, some existing projects might see an error such as:
Error: no schema available for module.fastly.<...> while reading state; this is a bug in Terraform and should be reported
This error is because the Terraform state file will have a different resource name to what's now exposed via the 1.0.0 release. To resolve this issue you'll need to first remove the old resource from the state file and then reimport the data using the new resource name.
As an example, if you had defined an fastly_service_acl_entries_v1 resource, then you could remove and reimport using the following commands (any brackets <...> should be replaced with actual values):
terraform state rm 'fastly_service_acl_entries_v1.<your_resource_name>["<your_acl_name>"]'
terraform import 'fastly_service_acl_entries.<your_resource_name>["<your_acl_name>"]' <service_id>/<acl_id>
terraform state rm 'fastly_service_v1.<your_resource_name>'
terraform import 'fastly_service_vcl.<your_resource_name>' <service_id>It's also recommended that you keep a backup of your state file so you can use it to reference any resource IDs necessary.
Logging resources have consistent naming format:
All logging resources now have a consistent naming convention with the provider prefixed with logging_.
bigquerylogging->logging_bigqueryblobstoragelogging->logging_blobstoragegcslogging->logging_gcshttpslogging->logging_httpslogentries->logging_logentriespapertrail->logging_papertrails3logging->logging_s3splunk->logging_splunksumologic->logging_sumologicsyslog->logging_syslog
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).