Terraform provider v1.x to v2 migration guide
Read time: 4 minutes
Last edited: Aug 08, 2024
Overview
This topic explains how to migrate your LaunchDarkly Terraform resources from v1.x to v2.0.
To learn more about v2.0, visit the LaunchDarkly Terraform provider changelog.
Here are the changes between versions 1 and 2 of the Terraform provider:
- Dropped support for Terraform 0.11 and below
- Removed deprecated attributes
- Standardized behavior of optional attributes
- Updated recommendation for managing projects and environments
- New required fields
- Restructured default variations on
launchdarkly_feature_flag
- Restructured
targets
block onlaunchdarkly_feature_flag_environment
Dropped support for Terraform 0.11 and below
The deprecation of Terraform 0.11 is ongoing. Version 2.0.0 of the LaunchDarkly Terraform provider only supports Terraform 0.12 and higher.
Removed deprecated attributes
The following previously-deprecated attributes are no longer supported:
targeting_enabled
on thelaunchdarkly_feature_flag_environment
resource was removed in favor ofon
.user_targets
on thelaunchdarkly_feature_flag_environment
resource was removed in favor oftargets
.flag_fallthrough
on thelaunchdarkly_feature_flag_environment
resource has been removed in favor offallthrough
. This field is required.enabled
on thelaunchdarkly_webhooks
resource has been removed in favor ofon
.
Standardized behavior of optional attributes
Except in a few special cases indicated in the Terraform provider documentation, optional attributes revert to their false
or null
value when not explicitly set or when removed from a configuration.
The following fields have been updated in line with this behavior with v2 of the provider:
on
on thelaunchdarkly_destination
resource defaults tofalse
.include_in_snippet
on thelaunchdarkly_project
resource defaults tofalse
.secure_mode
on thelaunchdarkly_environment
resource and inenvironments
blocks on thelaunchdarkly_project
resource defaults tofalse
.default_track_events
on thelaunchdarkly_environment
resource and inenvironments
blocks on thelaunchdarkly_project
resource defaults tofalse
.require_comments
on thelaunchdarkly_environment
resource and inenvironments
blocks on thelaunchdarkly_project
resource defaults tofalse
.confirm_changes
on thelaunchdarkly_environment
resource and inenvironments
blocks on thelaunchdarkly_project
resource defaults tofalse
.default_ttl
on thelaunchdarkly_environment
resource and inenvironments
blocks on thelaunchdarkly_project
resource defaults to0
.on
on thelaunchdarkly_feature_flag_environment
resource defaults tofalse
.on
was previouslytargeting_enabled
.- Removing
rules
blocks on thelaunchdarkly_feature_flag_environment
resource deletes the rule. - Removing
targets
blocks on thelaunchdarkly_feature_flag_environment
resource deletes the targets configuration in question.targets
was previouslyuser_targets
. - Removing
prerequisites
blocks on thelaunchdarkly_feature_flag_environment
resource removes the prerequisite from the feature flag environment. track_events
on thelaunchdarkly_feature_flag_environment
resource defaults tofalse
.
Updated recommendation for managing projects and environments
We no longer recommend you manage environments in Terraform as separate resources. We will continue to maintain the environment resource for the exception of environments in projects that are not managed using Terraform.
Manage all environments in projects maintained by Terraform as environments
config blocks on your launchdarkly_project
resource. The launchdarkly_project
resource now requires at least one environment be configured. The default test
and production
environments are not created unless you explicitly define them. Additionally, removing environments
blocks from a launchdarkly_project
resource configuration deletes that environment.
Importing project resources
Because of a bug in the 2.0.0 release, slightly different logic applies for project imports in v2.0.1.
To transition from managing environment resources independently to managing them as attribute blocks on a project resource, you must remove those environments from your Terraform state using terraform state rm launchdarkly_environment.<resource_name>
.
After you do this, the next apply will incorrectly show that the environments are going to change. This is incorrect. Your resources will be imported into the relevant project resource without being replaced and your SDK keys will not change.
When importing launchdarkly_project
resources, all of the project's environments are saved to the Terraform state whether or not they are explicitly defined on the import configuration, and are updated with subsequent applies. This means that any environments not included in your import configuration are torn down with any subsequent apply. If you want to manage project properties with Terraform but not nested environments, you can use Terraform's ignore changes lifecycle meta-argument.
Here is an example of the meta-argument:
New required fields
The following fields are now required:
fallthrough
andoff_variation
on thelaunchdarkly_feature_flag_environment
resource,on
on thelaunchdarkly_webhooks
resource, andenvironments
on thelaunchdarkly_project
resource.
Restructured default variations on launchdarkly_feature_flag
The configuration of default variations on the launchdarkly_feature_flag
resource has been restructured to match the shape of the HTTP response from the LaunchDarkly API.
You can use an optional defaults
block containing an on_variation
and off_variation
that evaluate to the index of the variation referenced.
For example, for a simple boolean flag with a 0-index variation of true
and a 1-index variation of false
, define the defaults like this:
For more information, read Terraform's launchdarkly_feature_flag
documentation.
Restructured targets block on launchdarkly_feature_flag_environment
The way targets
is configured on the launchdarkly_feature_flag_environment
resource has been restructured. targets
was previously user_targets
.
You can define user targets block in an order corresponding to the variations they are meant to be applied to, including empty blocks for variations without specific user targets. Alternatively, you may also define a variation index which allows the user to list targets
blocks in any order.
For more information, read Terraform's feature_flag_environment
documentation.