pulumi-azure-native
pulumi-azure-native copied to clipboard
pulumi
Allow temporary supression of all provider-specified replacements
When moving between API versions there are often schema or data changes which, within the same API version would cause replacement, but between different versions actually represent equivelent values. For example a SKU Name might change from "Basic" to "Base" to represent the same SKU.
Our approach to these issues is to try and spot the changes and add a migration to ignore the change: https://github.com/pulumi/pulumi-azure-native/blob/ba9989dc50a38ebe35e506da1680e37a394a061f/provider/pkg/provider/diff.go#L477-L481
However, when the provider does specify that a resource needs replacing, there is no way for the user to opt-out of the replacement and ask the provider to attempt to update the resource in-place. Instead, the user would have to open an issue and hope we can quickly roll out a patch with a new migration.
The only other option users has is to perform "state surgery" to manually edit the existing values in state to avoid the replacement. This can be fraught with issues though.
To give an alternative tool to let users unblock themselves, the user could specify a temporary environment variable such as PULUMI_AZURE_NATIVE_DISABLE_REPLACEMENTS=true to turn off the automatic replacements for a single deployment while upgrading the problematic resource.
If the user attempts to make a change to an immutable property of the resource then this should be rejected by the upstream service.
- See also: https://github.com/pulumi/pulumi-azure-native/issues/3768
Seems to me that the true "root cause" issue is a lack of migration logic that is otherwise being done thru "state surgery". Assumedly such migration logic would run automatically when one switched to a new representation of a resource (v2 to v3 for example).
The issue is that we don't know all places that we might need migrations until users report them. We can catch the high impact ones via upgrade tests, but we've got no mechanisms for highlighting all possible breaks. It's possible we can anticipate some of these via schema tools, but this is more focused on helping users with the few we miss.
We're also looking at improving the migration functionality in https://github.com/pulumi/pulumi-azure-native/issues/3767, though perhaps we could open another ticket to tackle trying to report on more of the required migrations.
This is almost implemented by PULUMI_FORCE_NEW_FROM_SUBTYPES, except there is no escape hatch for top-level types currently.
