Unable to change interface name on VpnIpsecPhase1Interface #105
Comments
|
Hi @blkistsg , It seems that I have not been able to reproduce your situation, can you please re-check again? My validation: Then I changed the interface name to 'port3' and executed it again. The result was successful: The operation mode of modifying the interface name here is consistent with the operation mode of CLI. By the way, can you please keep the line breaks in the terraform configuration you pasted? I have to reformat the content you pasted to analyze them. Thanks! |
|
What he's trying to change is the field name Not the interface name field. The name field is used to generate a new interface (if you check at |
|
Thanks @mbdraks. Hi @blkistsg Please do not try to expect the terraform resource to be created by modifying the name field only, you need to modify the name of the resource itself at the same time. This means: If only the name field is modified here, terraform will regard it as modifying the original resource fortios_vpnipsec_phase1interface.tr1abc. The correct approach is to modify the resource name at the same time: At this time terraform thinks that new resources fortios_vpnipsec_phase1interface.tr1cde will be created and the old ones fortios_vpnipsec_phase1interface.tr1abc will be destroyed. Refer: hashicorp/terraform#10792 , as terraform founder mitchellh and terraform developer apparentlymart described:
By the way, for the creation and modification of fortios_vpnipsec_phase1interface/fortios_vpnipsec_phase2interface/fortios_system_interface, the creation and modification can theoretically be realized in the following way: But if the resource fortios_vpnipsec_phase1interface is unchanged except for the resource name and the name field, the above method is not feasible, since terraform still has the following problems, as described in https://discuss.hashicorp.com/t/destroy-before-create/3980/3. which means the new fortios_vpnipsec_phase1interface may be created before the old fortios_vpnipsec_phase1interface is destroyed, if the fortios_vpnipsec_phase1interface is unchanged except for the resource name and the name field, the FGT creation will fail. In view of this situation, execute terraform destroy first, and then execute terraform apply is a better way. Thanks! |
|
@frankshen01 - This is not the behavior of other providers, for instance the AWS provider (probably the most mature). My understanding is that the provider should codify which settings are able to be modified directly vs. which need to force a complete destroy/create cycle of the resource. If I'm not mistaken, it is done by marking the schema elements for the resource which cannot be modified directly with the Here is the documentation in HashiCorp docs: https://www.terraform.io/docs/extend/schemas/schema-behaviors.html#forcenew |
|
Hi @StratusChris, you are totally right, your suggestion is wonderful. Thanks for the guidance. The bug will be fixed, it will be included in the next release (within a week). Thank you! |
|
Thanks so much @frankshen01 ! I suspect this same fix is needed for every resource where the name field is used as the object id in the FortiGate (almost all resources seem to fall under this since ids are not usually generated by the FortiGate). We really appreciate all the work you're doing on this provider, you're making really fast progress and it's very meaningful for us! |
|
Hi @StratusChris, thanks for your kind words. The feature has been supported and released, please see the latest version(v1.6.15): https://registry.terraform.io/providers/fortinetdev/fortios/latest. Let me know if you need anything else. Thanks again! |
|
I will go ahead to close this case, if you still have questions, feel free to reopen it or another case. |
FortiOS 6.4
My guess is that it is because it is trying to change it instead of delete and re-add it. I don't think you can just edit the name on the VpnIpsecPhase1Interface
The text was updated successfully, but these errors were encountered: