213 Commits (ccf19fbf5e2b61ba62efd1ac47a3a3fd3917d494)

Author	SHA1	Message	Date
Radek Simko	ecbfc365a0	Merge pull request #20157 from shinmog/conflictswith ... helper/schema: Add "part" to ConflictsWith validation error	7 years ago
Radek Simko	7861cc6141	Merge pull request #20309 from chanzuckerberg/ryanking/remove_lifecycle_comment ... helper/schema: Remove comment about nested schema.Resources having their own lifecycle	7 years ago
Radek Simko	350395d804	Add better comment	7 years ago
Alex Pilon	4bf43efcfd	move hcl2shim package to configs	7 years ago
Kristin Laemmert	bfd66083de	helper/schema: don't skip deprecation check during validation ... If an attribute was not wholly known, helper/schema was skipping the `validateType` function which (among other things) returned deprecation messages. This PR checks for deprecation before returning when skipping validateType.	7 years ago
James Bardin	7648f99bca	Merge pull request #22236 from hashicorp/jbardin/nil-in-config ... don't reflect nil in schema validation	7 years ago
James Bardin	016c4f782d	don't reflect nil in schema validation ... Nil values were not previously expected during validation, but they can appear in some situations with the new protocol. Add checks to prevent using zero reflect.Values.	7 years ago
James Bardin	4bed030d40	don't validate MinItems with unknowns in a block ... If there are unknowns, the block may have come from a dynamic declaration, and we can't validate MinItems. Once the blocks are expanded, we will get the full config for validation without any unknown values.	7 years ago
Alex Pilon	7f8f198719	remove UnknownVariabeValue from config and update references to shim	7 years ago
James Bardin	6055cb632e	filter unknowns from simple lists and maps in sdk ... While there was already a check in the sdk to filter unknowns from validation, it missed the case where those were in simple lists and maps.	7 years ago
James Bardin	c8a2f3840b	remove SkipCoreTypeCheck ... This experiment is no longer needed for handling computed blocks, since the legacy SDK can't reasonably handle Dynamic types, we need to remove this before the final release. Remove LegacySchema functions as well, since handling SkipCoreTypeCheck was the only thing left they were handling.	7 years ago
James Bardin	6bc36d3321	validate integers when using protoV5 ... The new type system only has a Number type, but helper schema differentiates between Int and Float values. Verify that a new config value is an integer during Validate, because the existing WeakDecode validation will decode a float value into an integer while the config FieldReader will attempt to parse the float exactly. Since we're limiting this to protoV5, we can be certain that any valid config value will be converted to an `int` type by the shims. The only case where an integral float value will appear is if the integer is out of range for the systems `int` type, but we also need to prevent that anyway since it would fail to read in the same manner.	7 years ago
Alex Somesan	275e0a53f2	Merge pull request #20851 from hashicorp/doc-validatefunc-maps ... Document that ValidateFunc works on maps.	7 years ago
Alex Somesan	01a169c66f	make fmt	7 years ago
Alex Somesan	0395c3ac58	Re-phrase docs to enumerate types which support ValidateFunc	7 years ago
James Bardin	4dbe6add77	Revert "helper/schema: Schema.AsSingle flag" ... This reverts commit 4c0c74571d.	7 years ago
Alex Somesan	ef681e527d	Rephrase for clarity	7 years ago
Alex Somesan	adebc65d95	Document that ValidateFunc works on maps.	7 years ago
Martin Atkins	7f860dc83e	helper/schema: Schema.SkipCoreTypeCheck flag ... When running in v0.12-and-higher mode, this will cause the SDK to report the type of the attribute as "any", effectively skipping type checking on the Core side altogether and checking only in the SDK and provider code. The practical impact of this is to restore the v0.11-style checking behavior of allowing object values to be missing certain attributes as long as they are marked as optional in the schema. The SDK can do this because it uses a unified schema model for both object values and nested blocks, while Terraform Core only supports the idea of "optional" when talking about attributes in nested blocks. This is a continuation of the pile of workarounds that also includes the ConfigMode and AsSingle fields, allowing providers to selectively opt out of new v0.12 behaviors in situations where they conflict with decisions made in the design of the providers in our old world where Terraform Core delegated _all_ validation to providers. This is designed as an opt-in so that we can limit its impact only to specific cases where it's needed and minimize the risk of regressions elsewhere. Providers should use this sparingly only in situations where prevailing usage disagrees with the new expectations of Terraform Core in v0.12. This commit only adds the flag, and does not implement any behavior for it yet. That means this commit can exist in both the v0.11 and v0.12 codebases, allowing for API compatibility. A subsequent commit for v0.12 (not included in v0.11) will then implement this behavior.	7 years ago
Paul Tyng	ea7e922007	oxford comma	7 years ago
Paul Tyng	ec9450a262	Fix limitations on Elem for TypeMap	7 years ago
Martin Atkins	1c8150428f	helper/schema: Schema.AsSingle flag ... This setting indicates that an attribute defined as TypeList or TypeSet should be presented to Terraform Core as a single value instead when running in Terraform v0.12 or later. It has no effect for Terraform v0.10 or v0.11. This commit just introduces the setting without any associated behavior, so it can be included in both the v0.12 and v0.11 branches. A subsequent commit only to the v0.12 branch will introduce the behavior as part of the protocol version 5 shims.	7 years ago
Martin Atkins	a6d322edec	helper/schema: ConfigMode field in *Schema ... This allows a provider developer slightly more control over how an SDK schema is mapped into the Terraform configuration language, overriding some default assumptions. ConfigMode overrides the default assumption that a schema with an Elem of type *Resource is to be mapped to configuration as a nested block, allowing mapping as an attribute containing an object type instead. These behaviors only apply when a provider is being used with Terraform v0.12 or later. They are ignored altogether in Terraform v0.11 mode, to preserve compatibility. We are adding these primarily to allow the v0.12 version of a resource type schema to be specified to match the prevailing usage of it in existing configurations, in situations where the default mapping to v0.12 concepts is not appropriate. This commit adds only the fields themselves and the InternalValidate rules for them. A subsequent commit for Terraform v0.12 will add the behavior as part of the protocol version 5 shim layer.	7 years ago
Sander van Harmelen	973e2a7cf9	core: add a context to the UIInput interface	7 years ago
Ryan King	58166ceaf5	remove comment about nested schema.Resources having their own lifecycle ... This comment seems to imply that you can put CRUD functions on nested schema.Resource objects. The comment goes back to the first commit to this file, but AFAICT this functionality has never been implemented.	7 years ago
James Bardin	55b4307767	add proto5 feature flag ... Add feature flag to allow special proto 5 behavior in helper/schema. This is Meant to be used as a last resort for shim-related bugs.	7 years ago
James Bardin	81a4e705b1	DiffSuppressFunc should noop diffs in sets ... Sets rely on diffs being complete for all elements, even when they are unchanged. When encountering a DiffSuppressFunc inside a set the diffs were being dropped entirely, possible causing set elements to be lost.	7 years ago
Garfield Freeman	22a09c2e3a	add "part" to ConflictsWith validation error	7 years ago
Martin Atkins	06acc3f6c8	helper/schema: Skip validation of unknown values ... With the introduction of explicit "null" in 0.12 it's possible for a value that is unknown during plan to become a known null during apply, so we need to slightly weaken our validation rules to accommodate that, in particular skipping the validation of conflicting attributes if the result could potentially be valid after the unknown values become known. This change is in the codepath that is common to both 0.12 and 0.11 callers, but that's safe because 0.11 re-runs validation during the apply step and so will still catch problems here, albeit in the apply step rather than in the plan step, thus matching the 0.12 behavior. This new behavior is a superset of the old in the sense that everything that was valid before is still valid. The implementation here also causes us to skip all other validation for an attribute whose value is unknown. Most of the downstream validation functions handle this directly anyway, but again this doesn't add any new failure cases, and should clean up some of the rough edges we've seen with unknown values in 0.11 once people upgrade to 0.12-compatible providers. Any issues we now short-circuit during planning will still be caught during apply. While working on this I found that the existing "Not a list" test was not actually testing the correct behavior, so this also includes a tweak to that to ensure that it really is checking the "should be a list" path rather than the "cannot be set" codepath it was inadvertently testing before.	7 years ago
Brian Flad	1e81a3e7fa	helper/schema: Always propagate NewComputed for previously zero value primative type attributes ... When the following conditions were met: * Schema attribute with a primative type (e.g. Type: TypeString) and Computed: true * Old state of attribute set to zero value for type (e.g. "") * Old state ID of resource set to non-empty (e.g. existing resource) Attempting to use CustomizeDiff with SetNewComputed() would result in the difference previously being discarded. This update ensures that previous zero values or resource existence does not influence the propagation of the computed update. Previously: ``` --- FAIL: TestSetNewComputed (0.00s) --- FAIL: TestSetNewComputed/NewComputed_should_always_propagate (0.00s) resource_diff_test.go:684: Expected (*terraform.InstanceDiff)(0xc00051cea0)({ mu: (sync.Mutex) { state: (int32) 0, sema: (uint32) 0 }, Attributes: (map[string]*terraform.ResourceAttrDiff) (len=1) { (string) (len=3) "foo": (*terraform.ResourceAttrDiff)(0xc0003dcec0)({ Old: (string) "", New: (string) "", NewComputed: (bool) true, NewRemoved: (bool) false, NewExtra: (interface {}) <nil>, RequiresNew: (bool) false, Sensitive: (bool) false, Type: (terraform.DiffAttrType) 0 }) }, Destroy: (bool) false, DestroyDeposed: (bool) false, DestroyTainted: (bool) false, Meta: (map[string]interface {}) <nil> }) , got (*terraform.InstanceDiff)(0xc00051ce80)({ mu: (sync.Mutex) { state: (int32) 0, sema: (uint32) 0 }, Attributes: (map[string]*terraform.ResourceAttrDiff) { }, Destroy: (bool) false, DestroyDeposed: (bool) false, DestroyTainted: (bool) false, Meta: (map[string]interface {}) <nil> }) --- FAIL: TestSchemaMap_Diff (0.01s) --- FAIL: TestSchemaMap_Diff/79-NewComputed_should_always_propagate_with_CustomizeDiff (0.00s) schema_test.go:3289: expected: *terraform.InstanceDiff{mu:sync.Mutex{state:0, sema:0x0}, Attributes:map[string]*terraform.ResourceAttrDiff{"foo":*terraform.ResourceAttrDiff{Old:"", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Sensitive:false, Type:0x0}}, Destroy:false, DestroyDeposed:false, DestroyTainted:false, Meta:map[string]interface {}(nil)} got: <nil> FAIL FAIL github.com/hashicorp/terraform/helper/schema 0.825s ```	8 years ago
Martin Atkins	58fa38b89a	helper/schema: Update docs for PromoteSingle ... This is no longer effective and should not be used in any new schema.	8 years ago
James Bardin	46b4c27dbe	create a SimpleDiff for the new provider shims ... Terraform now handles any actual "diffing" of resource, and the existing Diff functions are only used to shim the schema.Provider to the new methods. Since terraform is handling what used to be the Diff, the provider now should not modify the diff based on RequiresNew due to it interfering with the ignore_changes handling.	8 years ago
James Bardin	0d4d572c39	start work on helper/resource test fixtures ... The helper resource tests won't pass for now, as they use a terraform.MockProvider which can't be used in the schema.Provider shims.	8 years ago
James Bardin	bcc8be7400	add schema.InternalMap ... This exposes the internal schemaMap for use by the new provider shims.	8 years ago
Paul Tyng	74eae6825a	Fix typo in comment	8 years ago
James Bardin	61eae050ab	Merge pull request #17588 from creack/creack/fix-deepcopy-type ... Fix issue with deepcopy returning wrong type causing panic	8 years ago
Adam Lewandowski	56a330c533	Remove attribute values from ConflictsWith validation message	8 years ago
Guillaume J. Charmes	a4f941368b	Fix issue with deepcopy returning wrong type causing panic ... Signed-off-by: Guillaume J. Charmes <gcharmes@magicleap.com>	8 years ago
James McGill	035d56409f	helper/schema: handle TypeMap elem consistently with other collection types ... For historical reasons, the handling of element types for maps is inconsistent with other collection types. Here we begin a multi-step process to make it consistent, starting by supporting both the "consistent" form of using a schema.Schema and an existing erroneous form of using a schema.Type directly. In subsequent commits we will phase out the erroneous form and require the schema.Schema approach, the same as we do for TypeList and TypeSet.	8 years ago
Radek Simko	7af1c2b3a4	helper/schema: Prevent crash on removal of computed field in CustomizeDiff	8 years ago
James Bardin	4b49a323c3	go fmt ... slight change to go fmt coming in 0.10	8 years ago
James Bardin	0df8da59f7	add FIXMEs ... This new codepath with the getDiff "customzed" return value, along with the associated test need to be removed as soon as we can support unset fields from the config, so we don't continue to carry this broken behavior forward any longer than needed.	8 years ago
Chris Marchesi	cb5ce1d35e	helper/schema: Extend diffChange and bubble up customized values ... This extends the internal diffChange method so that ResourceDiff's implementation of it can report back whether or not the value came from a customized diff. This is an effort to work to preserve the pre-ResourceDiff behaviour that ignores the diff for computed keys when the old value was populated but the new value wasn't - this behaviour is actually being depended on by users that are using it to exploit using zero values in modules. This should allow both scenarios to co-exist by shifting the NewComputed exemption over to exempting values that come from diff customization.	8 years ago
James Bardin	643ef4334f	revert the change that broke the test case ... This reverts one of the changes from 6a4f7b0, which broke empty strings being seen as unset for computed values. This breaks a number of other tests, and is only an intermediate change for evaluating other solutions.	8 years ago
Radek Simko	2974d63e75	Merge pull request #16588 from hashicorp/f-panic-on-invalid-rd-set ... helper/schema: Opt-in panic on invalid ResourceData.Set	9 years ago
Radek Simko	e93d64b18c	helper/schema: Opt-in panic on invalid ResourceData.Set	9 years ago
Chris Marchesi	529d7e6dae	helper/schema: Review -> CustomizeDiff ... Restoring the naming of this field in the resource back to CustomizeDiff, as this is generally more descriptive of the process that's happening, despite the lengthy name.	9 years ago
Chris Marchesi	c6647a3bb7	helper/schema: CustomizeDiff -> Review ... To keep with the current convention of most other schema.Resource functional fields being fairly short, CustomizeDiff has been changed to "Review". It would be "Diff", however it is already used by existing functions in schema.Provider and schema.Resource.	9 years ago
Chris Marchesi	f7e42728b6	helper/schema: Remove unused Destroy check for CustomizeDiff ... Both Destroy and DestroyDeposed are not propagated down the diff stack, meaning that there is no way we can tell at this point if an instance is being destroyed or deposed, so this check would never be used. In this regard, Destroy never runs a diff down the stack at all, and a deposition check is not run until *after* the provider's diff function is called. To answer this question and close it off, we could either determine if a resource is deposed earlier, and propagate that down, or treat deposed resources like full destroy nodes, and not diff them at all (but rather making a diff with the only thing in it being DestroyDeposed flagged).	9 years ago
Chris Marchesi	ee769188d7	helper/schema: More CustomizeDiff test cases ... Added a few more test cases for CustomizeDiff, caught another error in the process. I think this is ready for review now, and possibly some real-world testing of the waters by way of porting some resources that would benefit from the feature.	9 years ago