You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if you update a resource, all outputs are shown as computed
during preview. This means that downstream resources might show a
replacement in the plan if they are using one of those output values.
There are some outputs that we know will not change unless the resource
is replaced (I'm referring to these as "stable" outputs). For stable
outputs we can copy the value from the state in order to show an
accurate preview.
The problem is that the CCAPI schema has no way of determining
programmatically which outputs are stable and which are not. We took the first step in #1891, but we can do better
Couple of ideas on how we can handle this.
readOnly properties that are also a primaryIdentifier
If a computed output is also part of the primary identifier of the resource then we should be able to assume that it is a stable output.
Create a schema overlay where users can contribute a list of stable outputs per resource. We already have an autoname overlay which we could adapt to be a generalized overlay.
Example
Note: this example won't show the issue after #1891 is merged.
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered:
Currently if you update a resource, all outputs are shown as computed
during preview. This means that downstream resources might show a
replacement in the plan if they are using one of those output values.
There are some outputs that we know will not change unless the resource
is replaced (I'm referring to these as \"stable\" outputs). For stable
outputs we can copy the value from the state in order to show an
accurate preview.
The problem is that the CCAPI schema has no way of determining
programmatically which outputs are stable and which are not. Because of
this, this PR introduces a heuristic to determine if an output is a
stable output.
- Is the value a `readOnlyProperty` in the schema? This indicates that
it is a computed output property
- Is the property the resource `id`, `arn` or `name`? If the id, arn, or
name is a computed property then we can assume that it is a stable
property. I don't know of any cases where these change outside of a
resource replacement.
This is not 100% coverage of stable properties, but it should get us
most of the impactful properties. To get close to 100% coverage we will
probably need a schema overlay where we can contribute to mapping these
stable properties for each resource.
Note: as part of this I had to add `readOnly` properties to
`metadata.json`
closes#1141, re #1892
What happened?
Currently if you update a resource, all outputs are shown as computed
during preview. This means that downstream resources might show a
replacement in the plan if they are using one of those output values.
There are some outputs that we know will not change unless the resource
is replaced (I'm referring to these as "stable" outputs). For stable
outputs we can copy the value from the state in order to show an
accurate preview.
The problem is that the CCAPI schema has no way of determining
programmatically which outputs are stable and which are not. We took the first step in #1891, but we can do better
Couple of ideas on how we can handle this.
readOnly
properties that are also aprimaryIdentifier
If a computed output is also part of the primary identifier of the resource then we should be able to assume that it is a stable output.
Example
Note: this example won't show the issue after #1891 is merged.
Output of
pulumi about
n/a
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: