[WIP] Add a ignoreRefreshChanges
resource option
#16015
Draft
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.
Introduce a new
ignoreRefreshChanges
resource option which is used to indicate changes that should be ignored during refresh.This allows users to indicate that they accept some level of "drift" between the Pulumi state and the real cloud provider state, and do not want to be told about it or reconcile it back into Pulumi state. This enables some parts of the cloud state to be intentionally managed "outside of Pulumi". It can also be used to work around "bugs" in providers where they are overly noisy in reporting changes from the cloud provider - like a
lastViewTime
property that changes freuently but doesn't represent true "drift" that the user wants to pay attention to.Importantly, this means that the diff won't be reported, but also that the changes won't be applied to state.
The
ignoreRefreshChanges
option applies to both input and output properties of a resource. This is different from the behavior ofignoreChanges
which only treats input properties.The special "*" property path ignores all properties, but also ignores the case where the resource is no longer found in the cloud, and instead keeps the resource with all of it's existing input and output properties. This seems reasonable as a "special case" because users must in practice ignore all properties to ignore the "discard", since all properties have changes (are no longer present).
Because this resource option is used during refresh, but the program is not evaluated during refresh, the
ignoreRefreshChanges
resource option must be applied and thenpulumi up
d before thepulumi refresh
can consider it. This is awkward in some cases where a refresh might need to happen before apulumi up
. So this PR also introduces apulumi state ignore-refresh-changes <urn> --path <path>
CLI command to directly set this option on a resource in the state (without doing apulumi up
).Logically - the difference between the two resource options is:
ignoreChanges
: Ignores cases where the program is different than the state for operations that are attempting to modify state based on what is in a Pulumi program.ignoreRefreshChanges
: Ignores cases where the cloud provider is different than the state for operations that are attepting to modify state based on what is in the cloud.Questions:
ignoreRefreshChanges
the right name? OrignoreDrift
?ignoreChanges
to also apply to refresh changes? This PR implements a separate resource option based on feedback that there could be use cases where you only want one or the other, but it is slighlty hard to come up with real-world examples, especially because ignoring refresh changes means it isn't necessarily "safe" to also be making changes via Pulumi (since those will inevitably silently conflict and show incorrect diffs relative to the actual diff that will apply in the cloud).ignoreRefreshChanges
? Are any of the places that currently listen toignoreChanges
for Read operations actually places that logically should have been using this new/expanded resource option?Still TODO: