Include API Version in input/state #3907
Draft
+75
−16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
Closes #3766
To be rebased onto master and generate SDKs.
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
apiVersion
as 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+update during the upgrade.In 3.x mode, the provider introduces a new
apiVersion
input property, with a constant value. The input property is NOT added to the resource args; it is always defaulted. In the future, a true input property might be added to support overrides. The purpose of having an input is to produce a diff (note that the diff logic is input-input in this provider) when the api version has changed. This leads to an update call against the new apiversion, to validate the inputs and refresh the state. An output property is added to the SDK.In a migration case, the old
apiVersion
isn'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 readingapiVersion
from old state during Diff. The ideal migration flow is:pulumi up
(to update the provider version) followed bypulumi refresh
(to update the resource's state.pulumi up
, and the provider compares old state to new input to see whether the api version is actually changing, e.g. via the use of a "default version" 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' apiversion.
Another aspect to this PR is the
apiVersion
output property and supporting thegetFoo
functions. The code generator must be careful to apply the output property to the resource type (as represented byisTopLevel
), not to functions. There is, however, a special "get" function where it does make sense to return anapiVersion
.