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
when changing the size of a volume the command should complete without errors and vol show should show all relevant information corectly
Actual Behavior
I created a volume with terraform apply and set the volume size to 6gb. The apply completed successfully and vol show looked good. Then I changed the size from 6gb to 10gb in the terraform config and ran a terraform apply and got the following output:
Plan: 0 to add, 1 to change, 0 to destroy.
netapp-ontap_storage_volume_resource.volbug: Modifying... [id=db9b58d1-8703-11ef-bc09-7f7f037f6475]
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to netapp-ontap_storage_volume_resource.volbug, provider "provider["registry.terraform.io/netapp/netapp-ontap"]" produced an unexpected new value: .nas.junction_path: was
│ cty.StringVal("/volbug"), but now cty.StringVal("").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
After this error, running a vol show indicated no junction path. I had the volume mounted on a remote client via nfs3 and the volume was still mounted and I still had write access.
If I rerun terraform apply the plan will indicate that it's setting the junction path but not changing the size. This time the command will complete successfully.
❯ terraform apply
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# netapp-ontap_storage_volume_resource.volbug will be created
+ resource "netapp-ontap_storage_volume_resource""volbug" {
+ aggregates = [
+ {
+ name = "aggr1"
},
]
+ analytics = (known after apply)
+ comment = (known after apply)
+ cx_profile_name = "aws_svm"
+ efficiency = (known after apply)
+ encryption = false
+ id = (known after apply)
+ language = (known after apply)
+ name = "volbug"
+ nas = {
+ export_policy_name = "open"
+ group_id = 0
+ junction_path = "/volbug"
+ security_style = "unix"
+ unix_permissions = 755
+ user_id = 0
}
+ qos_policy_group = (known after apply)
+ snaplock = {
+ type = "non_snaplock"
}
+ snapshot_policy = "ATCApps"
+ space = {
+ logical_space = {
+ enforcement = false
+ reporting = false
}
+ percent_snapshot_space = 5
+ size = 6
+ size_unit = "gb"
}
+ space_guarantee = "none"
+ state = (known after apply)
+ svm_name = "vs-aws-appsdev"
+ tiering = {
+ minimum_cooling_days = (known after apply)
+ policy_name = "none"
}
+ type = (known after apply)
}
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
netapp-ontap_storage_volume_resource.volbug: Creating...
netapp-ontap_storage_volume_resource.volbug: Creation complete after 2s [id=db9b58d1-8703-11ef-bc09-7f7f037f6475]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
❯ terraform apply --auto-approve
netapp-ontap_storage_volume_resource.volbug: Refreshing state... [id=db9b58d1-8703-11ef-bc09-7f7f037f6475]
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
# netapp-ontap_storage_volume_resource.volbug will be updated in-place~ resource "netapp-ontap_storage_volume_resource""volbug" {
~ analytics = {
~ state = "on" -> (known after apply)
} -> (known after apply)
~ comment = null -> (known after apply)
~ efficiency = {
+ compression = (known after apply)
+ policy_name = (known after apply)
} -> (known after apply)
id = "db9b58d1-8703-11ef-bc09-7f7f037f6475"~ language = "c.utf_8" -> (known after apply)
name = "volbug"~ qos_policy_group = null -> (known after apply)
~ space = {
~ size = 6 -> 10
# (3 unchanged attributes hidden)
}
~ state = "online" -> (known after apply)
~ tiering = {
~ minimum_cooling_days = 0 -> (known after apply)
# (1 unchanged attribute hidden)
}
~type = "rw" -> (known after apply)
# (8 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
netapp-ontap_storage_volume_resource.volbug: Modifying... [id=db9b58d1-8703-11ef-bc09-7f7f037f6475]
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to netapp-ontap_storage_volume_resource.volbug, provider "provider[\"registry.terraform.io/netapp/netapp-ontap\"]" produced an unexpected new value: .nas.junction_path: was
│ cty.StringVal("/volbug"), but now cty.StringVal("").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.╵❯ terraform apply --auto-approvenetapp-ontap_storage_volume_resource.volbug: Refreshing state... [id=db9b58d1-8703-11ef-bc09-7f7f037f6475]Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: ~ update in-placeTerraform will perform the following actions: # netapp-ontap_storage_volume_resource.volbug will be updated in-place ~ resource "netapp-ontap_storage_volume_resource" "volbug" { ~ analytics = { ~ state = "on" -> (known after apply) } -> (known after apply) ~ comment = null -> (known after apply) ~ efficiency = { + compression = (known after apply) + policy_name = (known after apply) } -> (known after apply) id = "db9b58d1-8703-11ef-bc09-7f7f037f6475" ~ language = "c.utf_8" -> (known after apply) name = "volbug" ~ nas = { ~ junction_path = "" -> "/volbug" # (5 unchanged attributes hidden) } ~ qos_policy_group = null -> (known after apply) ~ state = "online" -> (known after apply) ~ tiering = { ~ minimum_cooling_days = 0 -> (known after apply) # (1 unchanged attribute hidden) } ~ type = "rw" -> (known after apply) # (8 unchanged attributes hidden) }Plan: 0 to add, 1 to change, 0 to destroy.netapp-ontap_storage_volume_resource.volbug: Modifying... [id=db9b58d1-8703-11ef-bc09-7f7f037f6475]netapp-ontap_storage_volume_resource.volbug: Modifications complete after 1s [id=db9b58d1-8703-11ef-bc09-7f7f037f6475]Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
Terraform Core Version
1.9.5
ONTAP Provider Version
1.1.4
Affected Resource(s)
netapp-ontap_storage_volume_resource
Expected Behavior
when changing the size of a volume the command should complete without errors and vol show should show all relevant information corectly
Actual Behavior
I created a volume with terraform apply and set the volume size to 6gb. The apply completed successfully and vol show looked good. Then I changed the size from 6gb to 10gb in the terraform config and ran a terraform apply and got the following output:
Plan: 0 to add, 1 to change, 0 to destroy.
netapp-ontap_storage_volume_resource.volbug: Modifying... [id=db9b58d1-8703-11ef-bc09-7f7f037f6475]
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to netapp-ontap_storage_volume_resource.volbug, provider "provider["registry.terraform.io/netapp/netapp-ontap"]" produced an unexpected new value: .nas.junction_path: was
│ cty.StringVal("/volbug"), but now cty.StringVal("").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
After this error, running a vol show indicated no junction path. I had the volume mounted on a remote client via nfs3 and the volume was still mounted and I still had write access.
If I rerun terraform apply the plan will indicate that it's setting the junction path but not changing the size. This time the command will complete successfully.
volbug_terraform_config.zip
Relevant Error/Panic Output Snippet
Terraform Configuration Files
volbug_terraform_config.zip
Steps to Reproduce
apply a volume config
change the volume size
apply the config again
Debug Output
terraform_debug.log
Panic Output
No response
Important Factoids
this is being run against an svm in a cloud volumes ontap installation in aws
References
No response
Would you like to implement a fix?
No
The text was updated successfully, but these errors were encountered: