Comments (3)
The next version of terraform-plugin-sdk/v2, unreleased at the moment, but slated to be v2.11.0 adds an additional DiffSuppressOnRefresh
field to helper/schema.Schema
. When enabled, this checks the DiffSuppressFunc
during refresh. If the planned value matches the old state value via the DiffSuppressFunc
, the old value will be preserved (or put another way, the planned value will be ignored). This should help mitigate cases like these where the DiffSuppressFunc
implementations were likely put in place with the expectation that this would already happen in the SDK, however it previously did not.
We expect DiffSuppressOnRefresh
to be generally safe to apply in most cases where DiffSuppressFunc
is already being used, however it is not enabled by default for backwards compatibility.
The DiffSuppressOnRefresh
functionality may also resolve this particular issue, but verification is required and I don't have a quick reproduction handy, so I'm hesitant to immediately close this out.
from terraform-plugin-sdk.
I'm not entirely sure that DiffSuppressOnRefresh
can help in this particular case, because when we're importing we don't start with a configuration and so we don't have a distinct "original value" to preserve. If the import implementation and the refresh implementation disagree about how a particular value is normalized then DiffSuppressOnRefresh
would preserve the form the import produced, but since importing and refreshing are typically based on the same API calls anyway I would expect that they would be identically-normalized in most cases.
With that said, I may be misunderstanding the original problem statement here. I think I've never written tests for an import function in particular and so I'm not sure exactly how that test process behaves; perhaps there's something extra going on for that particular testing situation which changes the circumstances so that DiffSuppressOnRefresh
could be more helpful. 🤔
from terraform-plugin-sdk.
I filed this FR a while back so I don't have all the same context I did back then, but from what I remember: the Google provider uses ImportStateVerify
basically as a way to check that we were writing every field we read from the API back to state. If we didn't, then the test would fail because the "imported" resource wouldn't have the field (since import calls read), but the state would (since it was in the config).
As a contrived simple example, let's say we have a string field, and we don't care about case. In a real life situation, the config could have field = "foo"
, the API could return field = "FOO"
, and a DiffSuppressFunc
could ignore the case and make this not diff. In a test though, this same situation would show a diff and fail the test because the DiffSuppressFunc
doesn't get run. This could be worked around by putting field = "FOO"
in the test, but in a more complex situation, it wouldn't match user behavior as well.
Also cc @rileykarson who can probably talk about whether this is still a problem and may even be able to give real examples of trying to work around this.
from terraform-plugin-sdk.
Related Issues (20)
- Behaviour of `terraform providers schema` command for computed fields HOT 4
- `diff.GetOk` return `nil` for the value of `TypeList` defined in `TypeSet` HOT 1
- Not Helpful Err When Running Tests For Provider HOT 4
- Unsupported Field Type for Resource
- TypeSet resource wanting to destroy and recreate everything when diff is found HOT 2
- losing precision when using maximum value for a 64-bit signed integer
- helper/schema: Provide Functionality to Reduce Resident Memory Usage from Schemas HOT 1
- Consider Method for Disabling Legacy SDK Data Consistency Warning Log Demotion HOT 7
- Updates for Protocol Version 5.4 HOT 1
- Value out of range on 32-bit architecture HOT 3
- Update Go Module to Go 1.20 Minimum HOT 1
- `Schema.Set` adds an empty value when attempting to Patch HOT 1
- `meta.SDKVersion` reporting incorrect version HOT 6
- Terraform CloudFormation Multi Region Stacksets HOT 3
- Is it possible to have a dependency between 2 attributes? HOT 2
- `schema.ResourceData.GetRaw<whatever>()` not populated during provider configuration HOT 3
- Consider Migrating from mitchellh/mapstructure to go-viper/mapstructure
- Low performance in deduplicate strings function HOT 4
- ForceNew doesn't trigger resource recreation when defined on TypeSet, which leads to Update error HOT 1
- helper/resource: Add Go Deprecation Messages That Point To terraform-plugin-testing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from terraform-plugin-sdk.