You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are currently migrating existing Plugin-SDK based resources to Plugin Framework (Plugin protocol v6). In below resource, we have some optional+computed set block attributes where certain nested attributes if not configured/partially configured by the user in the config, the API/provider will still return those attributes. That response is currently persisted in the state.
In order to migrate these blocks to the Plugin Framework, we have tried using schema.SetNestedBlock but the returned plan after upgrade to the Framework-migrated resource is always non-empty. This will be a breaking change for our users.
What is the recommended non-breaking way to migrate collection attributes such as these?
Relevant provider source code
Terraform Plugin SDK based schema for "replication_specs" block:
main.tf:resource"mongodbatlas_cluster""cluster-no-blocks" {
project_id=mongodbatlas_project.project-tf.idprovider_name="AWS"name="tfCluster1"backing_provider_name="AWS"provider_region_name="US_EAST_1"provider_instance_size_name="M10"auto_scaling_compute_enabled=falseauto_scaling_compute_scale_down_enabled=falseprovider_auto_scaling_compute_min_instance_size="M10"provider_auto_scaling_compute_max_instance_size="M20"
}
terraform.tfstate (including only concerned blocks here due to large resource config):"replication_specs": [
{
"id":"....",
"num_shards":1,
"regions_config": [
{
"analytics_nodes":0,
"electable_nodes":3,
"priority":7,
"read_only_nodes":0,
"region_name":"US_EAST_1"
}
],
"zone_name":"Zone 1"
}
],
Use-case 2 (all blocks configured):
main.tf:resource"mongodbatlas_cluster""cluster-multi-region-all-blocks" {
project_id=mongodbatlas_project.project-tf.idname="cluster-test-multi-region"num_shards=1cloud_backup=truecluster_type="REPLICASET"provider_name="AWS"provider_instance_size_name="M10"advanced_configuration { # block can be partially configured by user minimum_enabled_tls_protocol="TLS1_2"default_read_concern="available"
}
bi_connector_config {
enabled=falseread_preference="secondary"
}
replication_specs {
num_shards=1regions_config {
region_name="US_EAST_1"electable_nodes=3priority=7read_only_nodes=0
}
regions_config {
region_name="US_EAST_2"electable_nodes=2priority=6read_only_nodes=0
}
regions_config {
region_name="US_WEST_1"electable_nodes=2priority=5read_only_nodes=2
}
}
}
terraform.tfstate (including only concerned blocks here due to large resource config):"replication_specs": [
{
"id":"....",
"num_shards":1,
"regions_config": [
{
"analytics_nodes":0,
"electable_nodes":2,
"priority":5,
"read_only_nodes":2,
"region_name":"US_WEST_1"
},
{
"analytics_nodes":0,
"electable_nodes":2,
"priority":6,
"read_only_nodes":0,
"region_name":"US_EAST_2"
},
{
"analytics_nodes":0,
"electable_nodes":3,
"priority":7,
"read_only_nodes":0,
"region_name":"US_EAST_1"
}
],
"zone_name":"ZoneName managed by Terraform"
}
],
Debug Output
Expected Behavior
After user upgrades to new provider version with the framework-migrated resource, user should not see any planned changes for optional+computed lists/set blocks when running terraform plan and not receive errors when running terraform apply.
Actual Behavior
On running terraform plan below plan was produced by Terraform: Use-case 1 (no blocks configured):
Module version
We are currently migrating existing Plugin-SDK based resources to Plugin Framework (Plugin protocol v6). In below resource, we have some optional+computed set block attributes where certain nested attributes if not configured/partially configured by the user in the config, the API/provider will still return those attributes. That response is currently persisted in the state.
In order to migrate these blocks to the Plugin Framework, we have tried using schema.SetNestedBlock but the returned plan after upgrade to the Framework-migrated resource is always non-empty. This will be a breaking change for our users.
What is the recommended non-breaking way to migrate collection attributes such as these?
Relevant provider source code
Terraform Plugin SDK based schema for "replication_specs" block:
Terraform Plugin Framework migrated schema:
Terraform Configuration Files
Use-case 1 (no blocks configured):
Use-case 2 (all blocks configured):
Debug Output
Expected Behavior
After user upgrades to new provider version with the framework-migrated resource, user should not see any planned changes for optional+computed lists/set blocks when running
terraform plan
and not receive errors when runningterraform apply
.Actual Behavior
On running
terraform plan
below plan was produced by Terraform:Use-case 1 (no blocks configured):
Use-case 2 (all blocks configured):
Steps to Reproduce
terraform init
for provider v.X (contains-Plugin-SDK-based-resource-implementation) for above resourceterraform plan
terraform apply
terraform plan
again -> plan returnsNo changes.
terraform init --upgrade
terraform plan
-> Plan is not emptyReferences
The text was updated successfully, but these errors were encountered: