266 Commits (6440c839474f052d8997bb5cec19c2743e5108e6)

Author	SHA1	Message	Date
Martin Atkins	4061cbed38	internal/getproviders: A new shared model for provider requirements ... We've been using the models from the "moduledeps" package to represent our provider dependencies everywhere since the idea of provider dependencies was introduced in Terraform 0.10, but that model is not convenient to use for any use-case other than the "terraform providers" command that needs individual-module-level detail. To make things easier for new codepaths working with the new-style provider installer, here we introduce a new model type getproviders.Requirements which is based on the type the new installer was already taking as its input. We have new methods in the states, configs, and earlyconfig packages to produce values of this type, and a helper to merge Requirements together so we can combine config-derived and state-derived requirements together during installation. The advantage of this new model over the moduledeps one is that all of recursive module walking is done up front and we produce a simple, flat structure that is more convenient for the main use-cases of selecting providers for installation and then finding providers in the local cache to use them for other operations. This new model is _not_ suitable for implementing "terraform providers" because it does not retain module-specific requirement details. Therefore we will likely keep using moduledeps for "terraform providers" for now, and then possibly at a later time consider specializing the moduledeps logic for only what "terraform providers" needs, because it seems to be the only use-case that needs to retain that level of detail.	6 years ago
James Bardin	cd045f6f4e	enable count and for_each in configuration	6 years ago
Kristin Laemmert	5b427ec648	addrs: Provider.IsLegacy and IsDefault functions ... * add IsLegacy and IsDefault funcs to addrs.Provider * add some test coverage	6 years ago
Kristin Laemmert	5f313a65ad	command: remove 0.12upgrade (#24403) ... * command: remove 0.12upgrade and related `configupgrade` library * leave deprecation warning for 0.12upgrade to point users to v0.12	6 years ago
Kristin Laemmert	ed1aebbeda	terraform: large refactor to use Provider from configs.Resource (#24396) ... * terraform: large refactor to use Provider from configs.Resource configs.Resource.ImpliedProvider() now returns a string; it is the callers' responsibility to turn that into an addrs.Provider if needed. GraphNodeProviderConsumer ProvidedBy() no longer returns nil (reverting to earlier, pre-provider-fqn behavior): it will return either the provider set in config, provider set in state, or the default provider.	6 years ago
Kristin Laemmert	ef19fb6203	configs: attach provider fqn to Resource (#24382) ... * configs: attach provider fqn to Resource	6 years ago
Martin Atkins	946eda3f3c	configs: Return diagnostics (almost) directly from ParseProviderSourceString ... This function can already produce suitable diagnostic messages which we'd like to preserve, but it cannot produce source location information, and so we'll amend the diagnostics to include that on the way out while retaining all of the other values in the diagnostics.	6 years ago
Kristin Laemmert	1c78b26012	terraform: provider source test (#24342) ... * configs: parse provider source string during module merge This was the smallest unit of work needed to start writing provider source tests! * Update configs/parser_test.go Co-Authored-By: Alisdair McDiarmid <alisdair@users.noreply.github.com>	6 years ago
James Bardin	8497adcb6e	AbsProviderConfig to use addrs.Module ... Change ModuleInstance to Module in AbsProviderConfig, because providers need to be handled before module expansion, and should not be used defined inside an expanded module at all. Renaming of the addrs type can happen later, when there's less work in-flight around provider configuration.	6 years ago
Kristin Laemmert	c7cc0afb80	Mildwonkey/ps schema (#24312) ... * add Config to AttachSchemaTransformer for providerFqn lookup * terraform: refactor ProvidedBy() to return nil when provider is not set in config or state	6 years ago
Paddy	e6592dc710	Add support for provider metadata to modules. (#22583) ... Implement a new provider_meta block in the terraform block of modules, allowing provider-keyed metadata to be communicated from HCL to provider binaries. Bundled in this change for minimal protocol version bumping is the addition of markdown support for attribute descriptions and the ability to indicate when an attribute is deprecated, so this information can be shown in the schema dump. Co-authored-by: Paul Tyng <paul@paultyng.net>	6 years ago
Martin Atkins	86f0b5191c	addrs: Stronger validation and normalization of provider namespace/type ... The provider FQN is becoming our primary identifier for a provider, so it's important that we are clear about the equality rules for these addresses and what characters are valid within them. We previously had a basic regex permitting ASCII letters and digits for validation and no normalization at all. We need to do at least case folding and UTF-8 normalization because these names will appear in file and directory names in case-insensitive filesystems and in repository names such as on GitHub. Since we're already using DNS-style normalization and validation rules for the hostname part, rather than defining an entirely new set of rules here we'll just treat the provider namespace and type as if they were single labels in a DNS name. Aside from some internal consistency, that also works out nicely because systems like GitHub use organization and repository names as part of hostnames (e.g. with GitHub Pages) and so tend to apply comparable constraints themselves. This introduces the possibility of names containing letters from alphabets other than the latin alphabet, and for latin letters with diacritics. That's consistent with our introduction of similar support for identifiers in the language in Terraform 0.12, and is intended to be more friendly to Terraform users throughout the world that might prefer to name their products using a different alphabet. This is also a further justification for using the DNS normalization rules: modern companies tend to choose product names that make good domain names, and now such names will be usable as Terraform provider names too.	6 years ago
Kristin Laemmert	6e2618d9be	terraform: ProviderTransform gets provider fqn from module ... Added configs.Module.ProviderForLocalProviderConfig which allows terraform.ProviderTransformer to get the provider FQN from the module, instead of assuming NewLegacyProvider.	6 years ago
Kristin Laemmert	72ec579807	configs/decodeRequiredProviders test: before comparing slices (#24114)	6 years ago
James Bardin	37e60cd883	fix comment text	6 years ago
James Bardin	84d1f5c688	convert destroy provisioner warnings to errors	6 years ago
Kristin Laemmert	47a16b0937	addrs: embed Provider in AbsProviderConfig instead of Type ... a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.	6 years ago
Kristin Laemmert	851e6dcdbb	configs: added map to configs.Module for provider local name lookup (#24039) ... * configs: added map of ProviderLocalNames to configs.Module We will need to lookup any user-supplied local names for a given FQN. This PR adds a map of ProviderLocalNames to the Module, along with adding tests for this and for decodeRequiredProvidersBlock. This also introduces the appearance of support for a required_provider "source" attribute, but ignores any user-supplied source and instead continues to assume that addrs.NewLegacyProvider is the way to go.	6 years ago
Kristin Laemmert	7eed30595a	moduledeps: replace ProviderInstance with addrs.Provider (#24017) ... * addrs: add ParseProviderSourceString function to parse fqns from tfconfig-inspect * moduledeps: use addrs.Provider instead of ProviderInstance	6 years ago
Kristin Laemmert	80ab551867	terraform: use addrs.Provider as map keys for provider schemas (#24002) ... This is a stepping-stone PR for the provider source project. In this PR "legcay-stype" FQNs are created from the provider name string. Future work involves encoding the FQN directly in the AbsProviderConfig and removing the calls to addrs.NewLegacyProvider().	6 years ago
Martin Atkins	8b511524d6	Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) ... * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>	6 years ago
Kristin Laemmert	6541775ce4	addrs: roll back change to Type field in ProviderConfig (#23937)	6 years ago
James Bardin	35107acc46	allow "terraform" in destroy provisioners ... The values supplied in terraform are static, and do not create any dependencies.	6 years ago
James Bardin	c376905adc	it's safe for destroy provisioners to access path ... The path values are statically loaded, and do not create any dependencies that could cause problems with destroy provisioners.	6 years ago
Kristin Laemmert	272cb44d3d	configs: extend module.ProviderRequirements to include the addrs.Provider instead of just version constraints. (#23843) ... Renamed file.ProviderRequirements to file.RequiredProviders to match the name of the block in the configuration. file.RequiredProviders contains the contents of the file(s); module.ProviderRequirements contains the parsed and merged provider requirements. Extended decodeRequiredProvidersBlock to parse the new provider source syntax (version only, it will ignore any other attributes). Added some tests; swapped deep.Equal with cmp.Equal in the terraform/module_dependencies_test.go because deep was not catching incorrect constraints.	6 years ago
Martin Atkins	ff4ea042c2	config: Allow module authors to specify validation rules for variables ... The existing "type" argument allows specifying a type constraint that allows for some basic validation, but often there are more constraints on a variable value than just its type. This new feature (requiring an experiment opt-in for now, while we refine it) allows specifying arbitrary validation rules for any variable which can then cause custom error messages to be returned when a caller provides an inappropriate value. variable "example" { validation { condition = var.example != "nope" error_message = "Example value must not be \"nope\"." } } The core parts of this are designed to do as little new work as possible when no validations are specified, and thus the main new checking codepath here can therefore only run when the experiment is enabled in order to permit having validations.	6 years ago
Kristin Laemmert	18dd1bb4d6	Mildwonkey/tfconfig upgrade (#23670) ... * deps: bump terraform-config-inspect library * configs: parse `version` in new required_providers block With the latest version of `terraform-config-inspect`, the required_providers attribute can now be a string or an object with attributes "source" and "version". This change allows parsing the version constraint from the new object while ignoring any given source attribute.	6 years ago
Martin Atkins	2b2ac1f6de	configs: use local set of go-getter detectors ... In an earlier change we switched to defining our own sets of detectors, getters, etc for go-getter in order to insulate us from upstream changes to those sets that might otherwise change the user-visible behavior of Terraform's module installer. However, we apparently neglected to actually refer to our local set of detectors, and continued to refer to the upstream set. Here we catch up with the latest detectors from upstream (taken from the version of go-getter we currently have vendored) and start using that fixed set. Currently we are maintaining these custom go-getter sets in two places due to the configload vs. initwd distinction. That was already true for goGetterGetters and goGetterDecompressors, and so I've preserved that for now just to keep this change relatively simple; in later change it would be nice to factor these "get with go getter" functions out into a shared location which we can call from both configload and initwd.	6 years ago
Kristin Laemmert	49fc53d1d1	provider source enhancements ... * configs: move ProviderConfigCompact[Str] from addrs to configs The configs package is aware of provider name and type (which are the same thing today, but expected to be two different things in a future release), and should be the source of truth for a provider config address. This is an intermediate step; the next step will change the returned types to something based in the configs package. * command: rename choosePlugins to chooseProviders to clarify scope of function * use `Provider.LegacyString()` (instead of `Provider.Type`) consistently * explicitly create legacy-style provider (continuing from above change)	6 years ago
Martin Atkins	b90fb25321	experiments: a mechanism for opt-in experimental language features ... Traditionally we've preferred to release new language features in major releases only, because we can then use the beta cycle to gather feedback on the feature and learn about any usability challenges or other situations we didn't consider during our design in time to make those changes before inclusion in a stable release. This "experiments" feature is intended to decouple the feedback cycle for new features from the major release rhythm, and thus allow us to release new features in minor releases by first releasing them as experimental for a minor release or two, adjust for any feedback gathered during that period, and then finally remove the experiment gate and enable the feature for everyone. The intended model here is that anything behind an experiment gate is subject to breaking changes even in patch releases, and so any module using these experimental features will be broken by a future Terraform upgrade. The behavior implemented here is: - Recognize a new "experiments" setting in the "terraform" block which allows module authors to explicitly opt in to experimental features. terraform { experiments = [resource_for_each] } - Generate a warning whenever loading a module that has experiments enabled, to avoid accidentally depending on experimental features and thus risking unexpected breakage on next Terraform upgrade. - We check the enabled experiments against the configuration at module load time, which means that experiments are scoped to a particular module. Enabling an experiment in one module does not automatically enable it in any other module. This experiments mechanism is itself an experiment, and so I'd like to use the resource for_each feature to trial it. Because any configuration using experiments is subject to breaking changes, we are free to adjust this experiments feature in future releases as we see fit, but once for_each is shipped without an experiment gate we'll be blocked from making significant changes to it until the next major release at least.	6 years ago
Kristin Laemmert	67fc4dd5a1	configs: move ProviderConfigCompact[Str] from addrs to configs ... The configs package is aware of provider name and type (which are the same thing today, but expected to be two different things in a future release), and should be the source of truth for a provider config address.	6 years ago
James Bardin	2fdf984cce	update destroy provisioner warning text ... Make it a little more user-oriented	6 years ago
Kristin Laemmert	e3416124cc	addrs: replace "Type string" with "Type Provider" in ProviderConfig ... * huge change to weave new addrs.Provider into addrs.ProviderConfig * terraform: do not include an empty string in the returned Providers / Provisioners - Fixed a minor bug where results included an extra empty string	6 years ago
James Bardin	6817c844bc	Merge pull request #23559 from hashicorp/jbardin/deprecate-destroy-references ... deprecation warning for destroy provisioner refs	6 years ago
Kristin Laemmert	9891d0354a	providers: use addrs.Provider as map keys for provider.Factory (#23548) ... * terraform/context: use new addrs.Provider as map key in provider factories * added NewLegacyProviderType and LegacyString funcs to make it explicit that these are temporary placeholders This PR introduces a new concept, provider fully-qualified name (FQN), encapsulated by the `addrs.Provider` struct.	6 years ago
James Bardin	8547603ff5	deprecation warning for destroy provisioner refs ... Add deprecation warning for references from destroy provisioners or their connections to external resources or values. In order to ensure resource destruction can be completed correctly, destroy nodes must be able to evaluate with only their instance state. We have sufficient information to validate destroy-time provisioners early on during the config loading process. Later on these can be converted to hard errors, and only allow self, count.index, and each.key in destroy provisioners. Limited the provisioner and block evaluation scope later on is tricky, but if the references can never be loaded, then they will never be encountered during evaluation.	6 years ago
James Bardin	6caa5d23e2	fix diagnostics handling ... Located all non-test paths where a Diagnostic type was assigned to an error variable.	7 years ago
Kristin Laemmert	2c78414724	configs/configupgrade: do not panic when int value is out of range (#23394) ... `terraform 0.12upgrade` assumes that the configuration has passed 0.11 init, but did not explicitly check that the configuration was valid. Certain issues would not get caught because the configuration was syntactically valid. In this case, int or float values out of range resulted in a panic from `Value()`. Since running a 0.11 validate command is a breaking change, this PR merely moves the `Value()` logic for ints and floats into `configupgrade` so the error can be returned to the user, instead of causing a panic.	7 years ago
Martin Atkins	91752f02da	configs: Warn for deprecated interpolation and quoted type constraints ... Following on from de652e22a2, this introduces deprecation warnings for when an attribute value expression is a template with only a single interpolation sequence, and for variable type constraints given in quotes. As with the previous commit, we allowed these deprecated forms with no warning for a few releases after v0.12.0 to ensure that folks who need to write cross-compatible modules for a while during upgrading would be able to do so, but we're now marking these as explicitly deprecated to guide users towards the new idiomatic forms. The "terraform 0.12upgrade" tool would've already updated configurations to not hit these warnings for those who had pre-existing configurations written for Terraform 0.11. The main target audience for these warnings are newcomers to Terraform who are learning from existing examples already published in various spots on the wider internet that may be showing older Terraform syntax, since those folks will not be running their configurations through the upgrade tool. These warnings will hopefully guide them towards modern Terraform usage during their initial experimentation, and thus reduce the chances of inadvertently adopting the less-readable legacy usage patterns in greenfield projects.	7 years ago
Calle Pettersson	73d574913d	configs: Mention leading underscores in invalid identifier message	7 years ago
Martin Atkins	79dc808614	configs: Emit warnings for deprecated quoted references/keywords ... Terraform 0.12.0 removed the need for putting references and keywords in quotes, but we disabled the deprecation warnings for the initial release in order to avoid creating noise for folks who were intentionally attempting to maintain modules that were cross-compatible with both Terraform 0.11 and Terraform 0.12. However, with Terraform 0.12 now more widely used, the lack of these warnings seems to be causing newcomers to copy the quoted versions from existing examples on the internet, which is perpetuating the old and confusing quoted form in newer configurations. In preparation for phasing out these deprecated forms altogether in a future major release, and for the shorter-term benefit of giving better feedback to newcomers when they are learning from outdated examples, we'll now re-enable those deprecation warnings, and be explicit that the old forms are intended for removal in a future release. In order to properly test this, we establish a new set of test configurations that explicitly mark which warnings they are expecting and verify that they do indeed produce those expected warnings. We also verify that the "success" tests do _not_ produce warnings, while removing the ones that were previously written to succeed but have their warnings ignored.	7 years ago
Pam Selle	cca36025d6	Merge pull request #22946 from hashicorp/kmoe/copy_dir_dotfiles ... remove dotfile exclusion in copyDir	7 years ago
Radek Simko	7860f55e4f	Version tools per Go convention under tools.go	7 years ago
Radek Simko	32f9722d9d	Replace import paths & set UA string where necessary	7 years ago
Martin Atkins	e21f0fa61e	backend/local: Handle interactive prompts for variables in UI layer ... During the 0.12 work we intended to move all of the variable value collection logic into the UI layer (command package and backend packages) and present them all together as a unified data structure to Terraform Core. However, we didn't quite succeed because the interactive prompts for unset required variables were still being handled _after_ calling into Terraform Core. Here we complete that earlier work by moving the interactive prompts for variables out into the UI layer too, thus allowing us to handle final validation of the variables all together in one place and do so in the UI layer where we have the most context still available about where all of these values are coming from. This allows us to fix a problem where previously disabling input with -input=false on the command line could cause Terraform Core to receive an incomplete set of variable values, and fail with a bad error message. As a consequence of this refactoring, the scope of terraform.Context.Input is now reduced to only gathering provider configuration arguments. Ideally that too would move into the UI layer somehow in a future commit, but that's a problem for another day.	7 years ago
James Bardin	1ee851f256	Merge pull request #22846 from hashicorp/jbardin/evaluate-resource ... Always evaluate resources in their entirety	7 years ago
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
Katy Moe	2c44a7aacb	remove dotfile exclusion in copyDir ... copyDir is used in configload/getter.go to copy previously downloaded modules instead of using the go-getter client every time. The go-getter client downloads dotfiles, but copyDir did not copy dotfiles, leading to inconsistent behaviour when reusing the same module source.	7 years ago
James Bardin	86bf674246	change GetResourceInstance to GetResource ... In order to allow lazy evaluation of resource indexes, we can't index resources immediately via GetResourceInstance. Change the evaluation to always return whole Resources via GetResource, and index individual instances during expression evaluation. This will allow us to always check for invalid index errors rather than returning an unknown value and ignoring it during apply.	7 years ago
James Bardin	13e2e10577	fix Min/Max validation during decoding ... We can only validate MinItems >= 1 (equiv to "Required") during decoding, as dynamic blocks each only decode as a single block. MaxItems cannot be validated at all, also because of dynamic blocks, which may have any number of blocks in the config.	7 years ago
James Bardin	731d4226d3	do not validate Min/Max Items in CoerceValue ... Due to both the nature of dynamic blocks, and the need for resources to sometimes communicate incomplete values, we cannot validate MinItems and MaxItems in CoerceValue.	7 years ago
James Bardin	3e03213485	Merge pull request #22478 from hashicorp/jbardin/coerce-value ... don't validate Min/Max block vals in CoerceValue	7 years ago
Daniel Schroeder	628b50f900	configs/configupgrade: typo fix (#22469)	7 years ago
James Bardin	554cedab8a	don't validate Min/Max block vals in CoerceValue ... A provider may not have the data to fill in required block values in all cases during the resource Read operation. This is more common in import, because there is no initial configuration or state, and it's possible some values are only provided in the configuration. The original intent of MinItems and MaxItems in the schema was to enforce configuration constraints, not to enforce what the resource could save in the state. Since the configuration is already statically validated, and the Schema is validated against the configuration in a separate step, we can drop these extra validation constraints in CoerceValue and relax it to only ensure the types conform to what is expected.	7 years ago
Pam Selle	9631e4c73d	Merge pull request #20571 from sergkondr/fix_misspelling ... fix misspelling	7 years ago
Alex Pilon	4bf43efcfd	move hcl2shim package to configs	7 years ago
James Bardin	5878527732	Merge pull request #22221 from hashicorp/jbardin/min-items ... MinItems with dynamic blocks	7 years ago
James Bardin	67dbd6d345	don't check MinItems with unknowns in blocks ... If a block was defined via "dynamic", there will be only one block value until the expansion is known. Since we can't detect dynamic blocks at this point, don't verify MinItems while there are unknown values in the config. The decoder spec can also only check for existence of a block, so limit the check to 0 or 1.	7 years ago
Pam Selle	360068b3cb	Merge pull request #21922 from pselle/resource_for_each ... Resource for_each	7 years ago
Pam Selle	e7d8ac5ad7	Remove panic, update comment	7 years ago
Thayne McCombs	7c678d104f	Add support for for_each for data blocks. ... This also fixes a few things with resource for_each: It makes validation more like validation for count. It makes sure the index is stored in the state properly.	7 years ago
Kristin Laemmert	66f4a48b8c	configs/configupgrade: fix panic on nil hilNode (#22181) ... In some cases (see #22020 for a specific example), the parsed hilNode can be nil. This causes a series of panics. Instead, return an error and move on.	7 years ago
Pam Selle	7d905f6777	Resource for_each	7 years ago
Alex Pilon	0450f487fa	move IsEmptyDir to configs package	7 years ago
James Bardin	8111050c66	ensure we record diagnostics from nested modules ... When loading nested modules, the child module diagnostics were dropped in the recursive function. This mean that the config from the submodules wasn't fully loaded, even though no errors were reported to the user. This caused further problems if the plan was stored in a plan file, when means only the partial configuration was stored for the subsequent apply operation, which would result in unexplained "Resource node has no configuration attached" errors later on. Also due to the child module diagnostics being lost, any newly added nested modules would be silently ignored until `init` was run again manually.	7 years ago
Radek Simko	5b9f2fafc8	Standardise directory name for test data	7 years ago
Kristin Laemmert	2a457115a3	configs: fix panic when the value is missing from version attribute in a provider block	7 years ago
Pam Selle	59c5cc4788	Merge pull request #21254 from davewongillies/gcs ... Add GCS source support for modules	7 years ago
Martin Atkins	e85093ce08	configs/configload: Don't panic when version constraint is added ... Previously, adding a version constraint to a module that was previously recorded without a version in the module manifest would cause a panic. Instead, we now use a slight variant of the "dependencies have changed" error that doesn't try to print out a specific version number.	7 years ago
David Gillies	8b45443b21	Add GCS source support for modules	7 years ago
Martin Atkins	004c2056a7	configs/configupgrade: Use single-line syntax for empty object exprs	7 years ago
Kristin Laemmert	14d625c850	configs/configupgrade: preserve in-line comments for lists (#21299) ... * configs/configupgrade: preserve in-line comments for lists The configupgrade tool was not writing `LineComments` for lists. Now it is! Fixes #21155	7 years ago
Radek Simko	a2ee9fc8f9	Merge pull request #21282 from hashicorp/configupgrade-err-msg-fmt ... configupgrade: Improve error message formatting	7 years ago
Radek Simko	8a6d1d62b6	stringer: Regenerate files with latest version	7 years ago
Radek Simko	81c20ed7ae	configupgrade: Improve error message formatting	7 years ago
Radek Simko	42ba7a3e00	configupgrade: Upgrade indexing of splat syntax	7 years ago
Radek Simko	1f5cadeec0	0.12upgrade: Return error for invalid reference	7 years ago
Martin Atkins	d7f23f0beb	configs/configupgrade: Don't panic if analyzer fails ... Previously we were trying to access a field of the analysis object before checking if analysis produced errors. The analysis function usually returns a nil analysis on error, so this would result in a panic whenever that happened. Now we'll dereference the analysis object pointer only after checking for errors, so we'll get a chance to report the analysis error to the user.	7 years ago
Martin Atkins	1bb47ab9a5	configs/configupgrade: Preserve comments on items in object exprs ... The expression upgrade functionality mostly ignores comments because in the old language the syntax prevented comments from appearing in the middle of expressions, but there was one exception: object expressions. Because HCL 1 used ObjectType both for blocks and for object expressions, that is the one situation where something we consider to be an expression could have inline attached comments in the old language. We migrate these here so we don't lose these comments that don't appear anywhere else. Other comments get gathered up into a general comments set maintained inside the analysis object and so will be printed out as required _between_ expressions, just as they did before.	7 years ago
Martin Atkins	bb118c37a2	configs: Handle "dynamic" blocks as special during override merging ... Previously we were treating "dynamic" blocks in configuration the same as any other block type when merging config bodies, so that dynamic blocks in the override would override any dynamic blocks present in the base, without considering the dynamic block type. It's more useful and intuitive for us to treat dynamic blocks as if they are instances of their given block type for the purpose of overriding. That means a foo block can be overridden by a dynamic "foo" block and vice-versa, and dynamic blocks of different types do not interact at all during overriding. This requires us to recognize dynamic blocks and treat them specially during decoding of a merged body. We leave them unexpanded here because this package is not responsible for dynamic block expansion (that happens in the sibling "lang" package) but we do decode them enough to recognize their labels so we can treat them as if they were blocks of the labelled type.	7 years ago
Martin Atkins	88e76fa9ef	configs/configschema: Introduce the NestingGroup mode for blocks ... In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.	7 years ago
Martin Atkins	a20084dc0e	configs/configschema: EmptyValue methods ... These helpers determine the value that would be used for a particular schema construct if the configuration construct it represents is not present (or, in the case of *Block, empty) in the configuration. This is different than cty.NullVal on the implied type because it might return non-null "empty" values for certain constructs if their absence would be reported as such during a decode with no required attributes or blocks.	7 years ago
Martin Atkins	26c1e40ad7	configs/configupgrade: Normalize number literals to decimal ... The v0.12 language supports numeric constants only in decimal notation, as a simplification. For rare situations where a different base is more appropriate, such as unix-style file modes, we've found it better for providers to accept a string containing a representation in the appropriate base, since that way the interpretation can be validated and it will be displayed in the same way in the rendered plan diff, in outputs, etc. We use tv.Value() here to mimick how HCL 1 itself would have interpreted these, and then format them back out in the canonical form, which implicitly converts any non-decimal constants to decimal on the way through.	7 years ago
Kristin Laemmert	3aa4ac43f9	configs/configupgrade: return if hil.Parse() produces an error. (#20920) ... Fixes #20917	7 years ago
Martin Atkins	6c5819f910	configs/configupgrade: Prefer block syntax for list-of-object attributes ... In order to preserve pre-v0.12 idiom for list-of-object attributes, we'll prefer to use block syntax for them except for the special situation where the user explicitly assigns an empty list, where attribute syntax is required in order to allow existing provider logic to differentiate from an implicit lack of blocks.	7 years ago
Kristin Laemmert	da52170797	configupgrade: fix test (#20863)	7 years ago
Kristin Laemmert	1baa1b907e	configs/configupgrade: detect invalid resource names and print a TODO (#20856) ... * configs/configupgrade: detect invalid resource names and print a TODO message In terraform 0.11 and prior it was possible to start a resource name with a number. This is no longer valid, as the resource name would would be ambiguous with number values in HCL expressions. Fixes #19919 * Update configs/configupgrade/test-fixtures/valid/invalid-resource-name/want/resource.tf Co-Authored-By: mildwonkey <mildwonkey@users.noreply.github.com>	7 years ago
Justin Downing	1e32ae243c	grammatical updates to comments and docs (#20195)	7 years ago
Martin Atkins	ea1d5f8fcb	vendor: go get github.com/hashicorp/hcl2@master ... This includes two upstream fixes: - Handle explicit JSON "null" consistently during decode of JSON syntax. - Properly detect the end of a "heredoc" when formatting to avoid messing up indentation of other lines following the heredoc.	7 years ago
Kristin Laemmert	2c60140cad	configs: do not panic if module version is a variable (#20681) ... Fixes #20653	7 years ago
Kristin Laemmert	a15a4acf2f	configs/configupgrade: detect possible relative module sources (#20646) ... * configs/configupgrade: detect possible relative module sources If a module source appears to be a relative local path but does not have a preceding ./, print a #TODO message for the user. * internal/initwd: limit go-getter detectors to those supported by terraform * internal/initwd: move isMaybeRelativeLocalPath check into getWithGoGetter To avoid making two calls to getter.Detect, which potentially makes non-trivial API calls, the "isMaybeRelativeLocalPath" check was moved to a later step and a custom error type was added so user-friendly diagnostics could be displayed in the event that a possible relative local path was detected.	7 years ago
Kristin Laemmert	0c5fd835ce	copyDir: detect if the module install path is a symlink to a directory (#20603) ... configs/configload and internal/initwd both had a copyDir function that would fail if the source directory contained a symlinked directory, because the os.FileMode.IsDir() returns false for symlinks. This PR adds a check for a symlink and copies that symlink in the target directory. It handles symlinks for both files and directories (with included tests). Fixes #20539	7 years ago
Sergey Kondrashov	43e7a7b552	fix misspelling	7 years ago
Martin Atkins	b217624d83	config/configupgrade: Test to show that list unwrapping works for sets ... This was already working but we had no tests to prove it.	7 years ago
Martin Atkins	dd43926761	configs/configupgrade: Fix up uses of the .count pseudo-attribute ... Terraform 0.11 and prior had an odd special case where a resource attribute access for "count" would be resolved as the count for the whole resource, rather than as an attribute of an individual instance as for all other attributes. Because Terraform 0.12 makes test_instance.foo appear as a list when count is set (so it can be used in other expressions), it's no longer possible to have an attribute in that position: lists don't have attributes. Fortunately we don't really need that special case anymore since it doesn't do anything we can't now do with the length(...) function. This upgrade rule, then, detects references like test_instance.foo.count and rewrites to length(test_instance.foo). As a special case, if test_instance.foo doesn't have "count" set then it just rewrites as the constant 1, which mimics what would've happened in that case in Terraform 0.11.	7 years ago
Martin Atkins	966eb39427	configs/configupgrade: Default arguments in "connection" blocks ... Prior to Terraform v0.12 it was possible for a provider to secretly set some default arguments for the "connection" block, which most commonly included a hard-coded type of "ssh" and a value from "host". In the interests of "explicit is better than implicit", Terraform 0.12 no longer has this feature and instead requires connection settings to be written explicitly in terms of the resource's exported attributes. For compatibility though, the upgrade tool will insert expressions that are as close as possible to the logic the provider formerly implemented, or in a few rare cases a TF-UPGRADE-TODO comment to fix it up manually. Some of the existing resource type implementations have incredibly complicated implementations of selecting a single host IP address to use and don't expose the result of that as an attribute, so for now we handle those via a complicated Terraform language expression achieving the same result. Ideally these providers would introduce a new attribute that exports the same address formerly exported as the hostname before their initial v0.12-compatible release, in which case we can simplify these to just reference the attribute in question. That would be preferable also because it would allow use of that exported attribute in other contexts, such as in a null_resource provisioner somewhere else or in an output to allow a caller to deal with the SSH part itself.	7 years ago
Martin Atkins	ac6e0e42dc	configs/configupgrade: Upgrade the bodies of "connection" blocks ... This uses the fixed "superset" schema from the main terraform package to apply our standard expression mapping, with the exception of "type" where interpolation sequences are not supported due to the type being evaluated early to retrieve the schema for decoding the rest.	7 years ago
Martin Atkins	e2ef51800a	configs/configupgrade: Upgrade the bodies of "provisioner" blocks ... Aside from the two special meta-arguments "connection" and "provisioner" this is just our standard mapping from schema to conversion rules, using the provisioner's configuration schema.	7 years ago
Martin Atkins	cdca8fbfe8	configs/configupgrade: Correct ignore_changes error message ... Due to a copy-paste error, this was using the message from the providers map in a "module" block. This new message is not particularly helpful, but we should only see it for a configuration that wouldn't have been valid in 0.11 either, and so it's unlikely to be displayed.	7 years ago
Martin Atkins	0095a944cd	configs/configupgrade: Include provisioner schemas in analysis ... We'll need these to migrate any "provisioner" blocks we find in the input configuration.	7 years ago