Include API Version in input/state#4015
Conversation
Does the PR have any schema changes?Looking good! No breaking changes found. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4015 +/- ##
==========================================
+ Coverage 57.53% 57.74% +0.21%
==========================================
Files 82 82
Lines 13099 13144 +45
==========================================
+ Hits 7536 7590 +54
+ Misses 4987 4976 -11
- Partials 576 578 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Some results using this test program. In upgrade case, the user sees no changes on their next up ( Now we refresh and see no change: Looking at the state file, we see |
|
This PR has been shipped in release v2.89.2. |
Overview
Closes #3766
This PR is aimed at improving the experience around api versions, e.g. when upgrading a resource to a new api version. Note that major version upgrades of this provider tend to change the 'default' versions of many resources.
In 2.x mode, the provider simply records the actual
azureApiVersionas an output property, but doesn't expose it at the SDK level. The rationale is to have the information available in "old state" +before+ the major upgrade is performed; this allows the provider to avoid a spurious diff and to make fewer update calls during the major upgrade.Note: these screenshots are outdated;
apiVersionis nowazureApiVersion.In 3.x mode, the provider introduces a new
azureApiVersioninput property, with a constant value. The input property is NOT added to the resource args; it is always defaulted inCheck. In the future, a true input property might be added to support overrides. The purpose of having a checked input is to produce a diff when the API version has changed (for whatever reason). This leads to an update call against the new API version of the resource, to validate the inputs and refresh the state.The output property that was added to state in 2.x is fully exposed in 3.x at the SDK level.
Migration
In a migration case, the old
azureApiVersionisn't yet known, and this may lead to a spurious (though harmless) update because the value goes from empty to known. We mitigate this by readingazureApiVersionfrom old state during Diff. The recommended migration flow is:pulumi up(to update the provider version) followed bypulumi refresh(to update the resource's state. Now there's anazureApiVersionin state for each 2.x resource.pulumi up, and the provider compares old state to new input to see whether the api version is actually changing, e.g. due to a change to the "default version" of a resource.For example, here's the impact to the state file after completing the migration as described. We see two affected resources: a resource group and a storage account, with the latter undergoing a change to the 'default' API version.
Invokes
Another aspect to this PR is the
azureApiVersionoutput property and supporting thegetFoofunctions. The code generator must be careful to apply the output property to the resource type (as represented byisResourceGetterandisTopLevel), not to functions. There is, however, a special "get" function where it does make sense to return theazureApiVersion.Provider Version
This PR ensures that the provider's
versionfield is used by its methods, rather than the static version.