Terraform provider v1.x to v2 migration guide
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
targetsblock 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_enabledon thelaunchdarkly_feature_flag_environmentresource was removed in favor ofon.user_targetson thelaunchdarkly_feature_flag_environmentresource was removed in favor oftargets.flag_fallthroughon thelaunchdarkly_feature_flag_environmentresource has been removed in favor offallthrough. This field is required.enabledon thelaunchdarkly_webhooksresource 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:
onon thelaunchdarkly_destinationresource defaults tofalse.include_in_snippeton thelaunchdarkly_projectresource defaults tofalse.secure_modeon thelaunchdarkly_environmentresource and inenvironmentsblocks on thelaunchdarkly_projectresource defaults tofalse.default_track_eventson thelaunchdarkly_environmentresource and inenvironmentsblocks on thelaunchdarkly_projectresource defaults tofalse.require_commentson thelaunchdarkly_environmentresource and inenvironmentsblocks on thelaunchdarkly_projectresource defaults tofalse.confirm_changeson thelaunchdarkly_environmentresource and inenvironmentsblocks on thelaunchdarkly_projectresource defaults tofalse.default_ttlon thelaunchdarkly_environmentresource and inenvironmentsblocks on thelaunchdarkly_projectresource defaults to0.onon thelaunchdarkly_feature_flag_environmentresource defaults tofalse.onwas previouslytargeting_enabled.- Removing
rulesblocks on thelaunchdarkly_feature_flag_environmentresource deletes the rule. - Removing
targetsblocks on thelaunchdarkly_feature_flag_environmentresource deletes the targets configuration in question.targetswas previouslyuser_targets. - Removing
prerequisitesblocks on thelaunchdarkly_feature_flag_environmentresource removes the prerequisite from the feature flag environment. track_eventson thelaunchdarkly_feature_flag_environmentresource 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.
Managing the transition of environment resources in your Terraform state
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:
fallthroughandoff_variationon thelaunchdarkly_feature_flag_environmentresource,onon thelaunchdarkly_webhooksresource, andenvironmentson thelaunchdarkly_projectresource.
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.