Azure
feat: replace triggered by
fixes #161
Implements a dynamic attribute that, when the value changes, will cause the resource to be recreated. This feature is present in the schema of AzureRM but cannot be implemented here as we use dynamic schema and have no source data.
Solves the problem when you need to recreate a resource when certain inputs change - e.g. VM SKU
Implements custom dynamic PlanModifier that ignores null value to allow consumers to have an escape hatch if things go awry.
Have spoken about this with @stemaMSFT an d @grayzu before and it was a simple add so I thought I'd implement. This is also easy to deprecate if we change to a schema based approach later on.
One advantage of this vs. a schema implementation is that the dynamic value can be populated with anything, even from dependant resources. For example:
- Replacing a policy assignment when certain properties of the referenced definition change.
pinging @ms-henglu for a review
Hi @matt-FFFFFF ,
Thank you for taking time to implement this feature, it looks great!
I have plan to support a schema based approach in 2.0, like replace_if_changes = ["sku.name"] which means it will replace the resource if the sku.name is changed. But I think we could have them both, because the replace_triggered_by could be used for some complicated use cases.
Hello @stemaMSFT and @grayzu, WDYT?
@matt-FFFFFF can you think of a scenario in which we would need both replace_triggered_by and replace_if_changes? Trying to see if these are redundant.
@matt-FFFFFF can you think of a scenario in which we would need both
replace_triggered_byandreplace_if_changes? Trying to see if these are redundant.
@stemaMSFT
This PR implements replace_triggered_by, which only works with references - e.g. variables, locals, etc.
If you had the scenario where you were using a literal value for a resource properties, then you would need the solution proposed as replace_if_changes in order to detect if a change to that literal value would cause a resource replacement.
However this is niche and the vast majority of scenarios could be covered by the solution implemented in this PR
@matt-FFFFFF I'm happy to incorporate this functionality, so long as we have clear dellineation between the two features within their flags/descriptors. Customers shouldn't have to open documentation to understand the difference, so I'm trying to think of a better name here... maybe replace_triggers_refs and replace_triggers_vals or something? Just throwing ideas out here.
@ms-henglu for FYI
I agree. The difference is nuanced and the naming should be clear to indicate the use cases if you choose to implement both.
Hi @matt-FFFFFF - Please help resolve the conflicts and rename the field to replace_triggers_vals. And let me know if you have any thoughts about other names.
Thanks!
@ms-henglu changed to: replace_triggers_external_values, I think this is clear when compared with replace_triggers_refs.
Have also added documentation with an example to make clear.
WDYT?
Hi @stemaMSFT - if you have any thoughts about the names, we are still able to modify them before the 2.0 beta release. For now, we'll go with the replace_triggers_external_values and replace_triggers_refs.