Closed rcoy-v closed 2 years ago
Kudos, SonarCloud Quality Gate passed!
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
0.0% Duplication
I did not add new tests, as I want to see if these changes would be considered for acceptance first. I can add them before merge.
Doing further testing, I don't think these changes are going to quite do what I was looking for either.
If the azurecaf_name
is applied first, then new resources are good to use the new values, and existing resources are not changed.
If azurecaf_name
and a new resource consuming a new result are applied at the same time, Terraform will error trying to actually resolve the key reference that does not exist yet.
Error: Missing map element
│
│ on example.tf line 25, in resource "azurerm_resource_group" "example":
│ 25: name = azurecaf_name.example.results.azurerm_resource_group
│ ├────────────────
│ │ azurecaf_name.example.results is map of string with 2 elements
│
│ This map does not have an element with the key "azurerm_resource_group".
If I try to use the lookup function, that also will produce an error since it tries to resolve immediately.
Error: Provider produced inconsistent final plan
│
│ When expanding the plan for azurerm_resource_group.example
│ to include new values learned so far during apply, provider
│ "registry.terraform.io/hashicorp/azurerm" produced an invalid new value for
│ .name: was cty.StringVal("default"), but now
│ cty.StringVal("rg-example").
│
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
Leaving this open for thoughts, but at this point I think I'm going to use azurecaf_name
with just a singular resource_type
and wrap it in a for_each
to get the type of reuse I'm looking for.
This is a little more complex changing the schema requirements name would require you to change the schema version this feature althought it is something that I have implemented in the version 3.0 you can see an early draft of it at https://github.com/aztfmod/terraform-provider-azurecaf/pull/90 you could make a pr to that branch because merging this feature will trigger a major version change we are almost finished with that
closing the merge to master as per @Nepomuceno feedback.
Description
Currently, the
azurecaf_name
resource is recreated for any change. This makes this resource much less appealing, especially when usingresource_types
, because it will cause downstream resources to be recreated as well. The changes in this pull request removes the need for a recreate; now every change is in-place with the same functionality.Main changes:
ForceNew
from all properties.resource_types
.resource_types
to a set, since rearrangingresource_types
should not cause changes.Examples
Current
Say this is already applied:
and these additions are made:
The result would be a recreate of both the
azurecaf_name
andazurerm_virtual_network
, and a create ofazurerm_subnet
.New
Using the same example above, the
azurecaf_name
would have an in-place change toresults
.azurerm_virtual_network
would not be changed in any way, since its value inresults
did not change.
azurerm_subnet` would still be a create.