165 Commits (449ea72e87da7e697ef7b68283a852cc9cc09045)

Author	SHA1	Message	Date
Martin Atkins	39e609d5fd	vendor: switch to HCL 2.0 in the HCL repository ... Previously we were using the experimental HCL 2 repository, but now we'll shift over to the v2 import path within the main HCL repository as part of actually releasing HCL 2.0 as stable. This is a mechanical search/replace to the new import paths. It also switches to the v2.0.0 release of HCL, which includes some new code that Terraform didn't previously have but should not change any behavior that matters for Terraform's purposes. For the moment the experimental HCL2 repository is still an indirect dependency via terraform-config-inspect, so it remains in our go.sum and vendor directories for the moment. Because terraform-config-inspect uses a much smaller subset of the HCL2 functionality, this does still manage to prune the vendor directory a little. A subsequent release of terraform-config-inspect should allow us to completely remove that old repository in a future commit.	7 years ago
Alex Pilon	c2bc88fc23	prune ResourceProviderFullName and its callers	7 years ago
Martin Atkins	5b08fd4f9f	config: Don't expose go implementation details in Resource.Count ... Previously we would return the raw error from strconv.ParseInt, which includes details in its text that expose implementation details and are thus not helpful to the user. Instead, we use a locally-defined error message that talks only about what the caller is expected to know: that count should be parsable as an integer.	8 years ago
Martin Atkins	87e1fb4d66	config: a nicer error message for invalid provider constraints ... Previously our error message here was confusing and redundant: Error starting operation: provider.null: invalid version constraint "not valid": Malformed constraint: not valid Instead, we'll generate a full HCL2 diagnostic here, which results in something (subjectively) nicer: Error: Invalid provider version constraint The value "@ 1.0.0" given for provider.null is not a valid version constraint. At the moment this message is an outlier in that the other validation errors are all still just plain Go errors, but over time we'll want to adjust all of these to be full diagnostics so that we can embed source range information in them to help the user find the offending configuration.	8 years ago
James Bardin	e0b2c64645	accessing count directly in an output should is OK ... There should be no warning when accessing a resource's count value directly in an output.	8 years ago
James Bardin	048af6e237	Add test fixture to check for warnings	9 years ago
Martin Atkins	cc5e480378	config: detect and warn about access to "counted" attributes ... A common pattern is to conditionally assign to "count" in a resource in order to decide dynamically whether it should be created. In that situation it's necessary to refer to attributes of the resource using the splat syntax, but historically we didn't show errors in output expressions and so people "got away with" incorrect usage in that context. The intent of this warning is to catch potentially-problematic usage of attributes on such resources even if the count happens to be currently set dynamically to 1, which would not generate the error. Then the user can quickly locate and fix the incorrect usage regardless of the current value.	9 years ago
Martin Atkins	ba0514106a	return tfdiags.Diagnostics from validation methods ... Validation is the best time to return detailed diagnostics to the user since we're much more likely to have source location information, etc than we are in later operations. This change doesn't actually add any detail to the messages yet, but it changes the interface so that we can gradually introduce more detailed diagnostics over time. While here there are some minor adjustments to some of the messages to improve their consistency with terminology we use elsewhere.	9 years ago
James Bardin	8619f566bb	validate providers passed to a module exist ... This validation was lost in the migration of inheritance back to core. Make sure a module configuraton doesn't specifiy a provider that doesn't exist.	9 years ago
James Bardin	b79adeae02	save resolved providers for resources to state ... Use the ResourceState.Provider field to store the full name of the provider used during apply. This field is only used when a resource is removed from the config, and will allow that resource to be removed by the exact same provider with which it was created. Modify the locations which might accept the alue of the ResourceState.Provider field to detect that the name is resolved.	9 years ago
James Bardin	57470f6bf5	remove ProviderConfig Path and Inherited fields ... maving all inheritance into core	9 years ago
James Bardin	1756b3d09f	ProviderConfig needs an Inherited flag ... If a provider configuration is inherited from another module, any interpolations in that config won't have variables declared locally. Let the config only be validated in it's original location.	9 years ago
James Bardin	2e505083cd	change ProviderConfig.Scope to Path ... Though it's intended for "interpolation scope", Path is generally used for this elsewhere.	9 years ago
James Bardin	29e5a355b9	add "version" and "provider" to module config ... Add the Version and Providers fields to the module config. Add ProviderConfig.Scope, which will be used to record the original path of a ProviderConfig for interpolation.	9 years ago
Martin Atkins	bbf9725134	config: Validate resource "count" for HCL2-specified resources ... This early validation uses interpolation of a placeholder value to achieve some "best effort" validation of the validity of the count attribute. Since HCL2-specified resources can't be interpolated using the main interpolator, here we branch and use the HCL2 API to do a largely-equivalent (though slightly less accurate) check. In the long run we don't really need this extra check at all, since the validation walk does a more accurate version of the same thing. However, we're preserving this for now in the interests of minimizing the amount of change for the main codepath during our experiment.	9 years ago
Martin Atkins	0a342e8dc2	config: allow local value interpolations in count ... There is some additional, early validation on the "count" meta-argument that verifies that only suitable variable types are used, and adding local values to this whitelist was missed in the initial implementation.	9 years ago
Martin Atkins	f6797d6cb0	config: parsing of "locals" blocks in configuration	9 years ago
Martin Atkins	f70318097a	config: fix provider version constraint validation ... Previously we were using the "semver" library to parse version constraints, but we switched over to go-version and encapsulated it inside our own plugin/discovery package to reduce dependency sprawl in the code. This particular situation was missed when updating references to the new path, which meant that our validation code disagreed with the rest of the code about what is considered a valid version constraint string. By using the correct function, we ensure that we catch early any invalid versions.	9 years ago
Martin Atkins	0b14c2cdb3	Resolve resource provider types in config package ... Previously the logic for inferring a provider type from a resource name was buried a utility function in the 'terraform' package. Instead here we lift it up into the 'config' package where we can make broader use of it and where it's easier to discover.	9 years ago
Martin Atkins	7e7d4c70df	config: allow version constraints on providers, but validate them ... We now accept syntactically-valid version constraints on provider blocks, though we still don't actually do anything with them.	9 years ago
Martin Atkins	73fc9985b2	config: add "version" argument to provider blocks, disabled ... In future we will support version constraints on providers, so we're reserving this attribute name that is currently not used by any builtin providers. For now using this will produce an error, since the rest of Terraform (outside of the config parser) doesn't currently have this notion and we don't want people to start trying to use it until its behavior is fully defined and implemented. It may be used by third-party providers, so this is a breaking change worth warning about in CHANGELOG but one whose impact should be small. Any third-party providers using this name should migrate to using a new attribute name instead moving forward.	9 years ago
Martin Atkins	410b60cb7f	Stop requiring multi-vars (splats) to be in array brackets ... Prior to Terraform 0.7, lists in Terraform were just a shallow abstraction on top of strings with a magic delimiter between items. Wrapping a single string in brackets in the configuration was Terraform's prompt that it needed to split the string on that delimiter during interpolation. In 0.7, when first-class lists were added, this convention was preserved by flattening lists-of-lists by one level when they were encountered in configuration. However, there was an oversight in that change where it did not correctly handle the case where the inner list was unknown. In #14135 we removed some code that was flattening partially-unknown lists into fully-unknown (untyped) values. This inadvertently exposed the missed case from the previous paragraph, causing issues for list-wrapped splat expressions with unknown members. While this worked fine for resources, due to some fixup done inside helper/schema, this did not work for other interpolation contexts such as module blocks. Various attempts to fix this up and restore the flattening behavior selectively were unsuccessful, due to a proliferation of assumptions all over the core code that would be too risky to change just to fix this bug. This change, then, takes the different approach of removing the requirement that splats be presented inside list brackets. This requirement didn't make much sense anymore anyway, since no other list-returning expression had this constraint and so the rest of Terraform was already successfully dealing with both cases. This leaves us with two different scenarios: - For resource arguments, existing normalization code in helper/schema does its own flattening that preserves compatibility with the common practice of using bracketed splats. This change proves this with a test within the "test" provider that exercises the whole Terraform core and helper/schema stack that assigns bracketed splats to list and set attributes. - For arguments in other blocks, such as in module callsites, the interpolator's own flattening behavior applies to known lists, preserving compatibility with configurations from before partially-computed splats were possible, but those wishing to use partially-computed splats are required to drop the surrounding brackets. This is less concerning because this scenario was introduced only in 0.9.5, so the scope for breakage is limited to those who adopted this new feature quickly after upgrading. As of this commit, the recommendation is to stop using brackets around splats but the old form continues to be supported for backward compatibility. In a future _major_ version of Terraform we will probably phase out this legacy form to improve consistency, but for now both forms are acceptable at the expense of some (pre-existing) weird behavior when _actual_ lists-of-lists are used. This addresses #14521 by officially adopting the suggested workaround of dropping the brackets around the splat. However, it doesn't yet allow passing of a partially-unknown list between modules: that still violates assumptions in Terraform's core, so for the moment partially-unknown lists work only within a _single_ interpolation expression, and cannot be passed around between expressions. Until more holistic work is done to improve Terraform's type handling, passing a partially-unknown splat through to a module will result in a fully-unknown list emerging on the other side, just as was the case before #14135; this change just addresses the fact that this was failing with an error in 0.9.5.	9 years ago
Patrick Decat	392166faea	Typo: now => no (#14493) ... > This validation checks that there are now splat variables referencing ourself. This currently is not allowed. => > This validation checks that there are no splat variables referencing ourself. This currently is not allowed.	9 years ago
Justin Campbell	c1c3127d8e	config: Generate error copy from valid types map ... Renders as: ``` Variable 'invalid_type' type must be one of [string, map, list] - 'not_a_type' is not a valid type ```	9 years ago
Justin Campbell	cf775ded0e	config: Add 'list' to variable type error message	9 years ago
Martin Atkins	76dca009e0	Allow escaped interpolation-like sequences in variable defaults ... The variable validator assumes that any AST node it gets from an interpolation walk is an indicator of an interpolation. Unfortunately, back in f223be15 we changed the interpolation walker to emit a LiteralNode as a way to signal that the result is a literal but not identical to the input due to escapes. The existence of this issue suggests a bit of a design smell in that the interpolation walker interface at first glance appears to skip over all literals, but it actually emits them in this one situation. In the long run we should perhaps think about whether the abstraction is right here, but this is a shallow, tactical change that fixes #13001.	9 years ago
Mitchell Hashimoto	e2ca2c5911	config: allow TerraformVars in count	9 years ago
Mitchell Hashimoto	6b4c007894	config: validate backend configuration can't contain interpolations	9 years ago
Mitchell Hashimoto	b6bfc4798d	config: Resource.Count should type check ... Fixes #11800 Type check the value of count so we don't panic on the conversion. I wondered "why didn't we do this before?" There is no excuse for NOT doing it at all but the reasoning was beacuse prior to the list/map work in 0.7, the value couldn't be anything other than a string since any primitive can turn into a string. Regardless, we should've always done this.	9 years ago
Mitchell Hashimoto	cf46e1c3e0	terraform: don't validate computed values in validate ... This disables the computed value check for `count` during the validation pass. This enables partial support for #3888 or #1497: as long as the value is non-computed during the plan, complex values will work in counts. **Notably, this allows data source values to be present in counts!** The "count" value can be disabled during validation safely because we can treat it as if any field that uses `count.index` is computed for validation. We then validate a single instance (as if `count = 1`) just to make sure all required fields are set.	9 years ago
Mitchell Hashimoto	7b342100d0	config: add "backend" loading to the Terraform section	9 years ago
Mitchell Hashimoto	928fce71f7	config: parse "when" and "on_failure" on provisioners	9 years ago
Mitchell Hashimoto	0c30caec7d	config: smarter provider alias usage validation ... Fixes #4789 This improves the validation that valid provider aliases are used. Previously, we required that provider aliases be defined in every module they're used. This isn't correct because the alias may be used in a parent module and inherited. This removes that validation and creates the validation that a provider alias must be defined in the used module or _any parent_. This allows inheritance to work properly. We've always had this type of validation for aliases because we believe its a good UX tradeoff: typo-ing an alias is really painful, so we require declaration of alias usage. It may add a small burden to declare, but since relatively few aliases are used, it improves the scenario where a user fat-fingers an alias name.	9 years ago
Mitchell Hashimoto	3878b8b093	config: Merge respects Terraform blocks, provider aliases, and more ... Fixes #10715 `config.Merge` was not updated to support a number of new features. This updates the codepath to merge various fields, including the `terraform` block which was the issue in #10715. The `Merge` API is called when an `_override` file is present to _merge_ configurations. Normally configurations are _appended_. Only an override file triggers a _merge_. I started working on a generic library to do this automatically awhile back but never finished it. This might motivate me to do so. In the interest of getting a fix out though, we'll continue the manual approach.	9 years ago
Mitchell Hashimoto	b5f1738e17	config: allow IDs to start with numbers	10 years ago
Mitchell Hashimoto	8b9e2c17cc	config: fix NameRegexp validation to allow single-char names	10 years ago
Mitchell Hashimoto	6b458160b9	config: disallow names starting with ints ... Fixes #10597 This disallows any names for variables, modules, etc. starting with ints. This causes parse errors with the new HIL parser and actually causes long term ambiguities if we allow this. I've also updated the upgrade guide to note this as a backwards compatibility and how people can fix this going forward.	10 years ago
Mitchell Hashimoto	3665fea2db	config: validate that data sources don't have provisioners	10 years ago
Martin Atkins	399542a168	core: allow outputs to have descriptions (#9722) ... We allow variables to have descriptions specified, as additional context for a module user as to what should be provided for a given variable. We previously lacked a similar mechanism for outputs. Since they too are part of a module's public interface, it makes sense to be able to add descriptions for these for symmetry's sake. This change makes a "description" attribute valid within an "output" configuration block and stores it within the configuration data structure, but doesn't yet do anything further with it. For now this is useful only for third-party tools that might parse a module's config to generate user documentation; later we could expose the descriptions as part of the "apply" output, but that is left for a separate change.	10 years ago
Mitchell Hashimoto	25d19ef3d0	Merge pull request #10080 from hashicorp/f-tf-version ... terraform: support version requirement in configuration	10 years ago
Mitchell Hashimoto	df34fa88ce	Merge pull request #10076 from hashicorp/f-depend-module ... terraform: depends_on can reference entire modules	10 years ago
Mitchell Hashimoto	85d3439fa0	config: parse and validate terraform.required_version	10 years ago
Mitchell Hashimoto	576b61a21d	config: validate depends_on with module values	10 years ago
Mitchell Hashimoto	10426ba619	config: parse depends_on for outputs	10 years ago
Mitchell Hashimoto	694b16de5d	config: ignore_changes cannot have interpolations ... This is the limitation of all lifecycle attributes currently. Right now, interpolations are allowed through and the user ends up thinking it should work. We should give an error. In the future it should be possible to support some minimal set of interpolations (static variables, data sources even perhaps) but for now let's validate that this doesn't work.	10 years ago
Sander van Harmelen	47dd1ad153	Add wildcard (match all) support to ignore_changes (#8599)	10 years ago
Mitchell Hashimoto	fbf06e2a59	config: vars must be unique	10 years ago
Mitchell Hashimoto	099293b690	config: outputs must be unique	10 years ago
Mitchell Hashimoto	f4faf2274b	config: count can't be a SimpleVariable	10 years ago
James Nugent	01cd596c60	core: Fix detection of empty list/map defaults ... This commit changes config parsing from weak decoding lists and maps into []string and map[string]string respectively to decode into []interface{} and map[string]interface{} respectively. This is in order to take advantage of the work integrated in #7082 to defeat the backward compatibility features of the mapstructure library. Test coverage of loading empty variables and validating their default types against expectation.	10 years ago