[WIP] Add a ignoreRefreshChanges resource option
#16015
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Makes two changes to the handling of ignoreChanges: 1. Stores the ignoreChanges configuration for each resource in the state file 2. Applies the ignoreChanges configuration from the state file as part of processing a refresh This allows users to use `ignoreChanges` to prevent refresh diffs being reported when changes happen in the cloud provider that they do not want to bring back into their Pulumi state. This can be used to acknowledge that part or all of a resource may change in the cloud provider, but the user is okay with this and doesn't want to be notified about it during refresh. Importantly, this means that the diff won't be reported, but also that the changes won't be applied to state. The ignoreChanges option when applied to a refresh operation applies to *both* input and output properties of the resource. This is different from the behavior during a normal update operation, where ignoreChanges only applies to 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. Because the program is not run for refresh operations, users must apply the `ignoreChanges` via a `pulumi up` first, and then future `pulumi refresh` or `pulumi refresh --preview-only` oeprations will ignore the specificd changes. This is unfortunate, but the only option we have unless/until Pulumi fundamentally changes it's approach to refresh and decides to run the program as part of computing the resource state (and options) to use during the refresh.
Introduce a new ignoreRefreshChanges resource option which is used to indicate changes that should be ignored during refresh. Use this instead of interpreting ignoreChanges as applying to both update and refresh operations.
Ensures users can apply this to state without needing to do a `pulumi up`.
lukehoban
force-pushed
the
lukehoban/ignoreRefreshChanges
branch
from
a07ce96
to
8de2a41
Compare
Changelog[uncommitted] (2024-04-22)Features
|
|
We really need this for pulumi-aws pulumi/pulumi-aws#2246 and possibly more. Couple of other thoughts:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
ignoreRefreshChangesresource 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
lastViewTimeproperty 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
ignoreRefreshChangesoption applies to both input and output properties of a resource. This is different from the behavior ofignoreChangeswhich 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
ignoreRefreshChangesresource option must be applied and thenpulumi upd before thepulumi refreshcan 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:
ignoreRefreshChangesthe right name? OrignoreDrift?ignoreChangesto 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 toignoreChangesfor Read operations actually places that logically should have been using this new/expanded resource option?Still TODO: