170 Commits (8421abaca0fd577d4ada2ea1b9b10dbadfac8a1a)

Author	SHA1	Message	Date
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	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
Pam Selle	37d16b2f79	Deletions from backend local	6 years ago
Pam Selle	bb3d513c4f	Some deletions from static analysis	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
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	6caa5d23e2	fix diagnostics handling ... Located all non-test paths where a Diagnostic type was assigned to an error variable.	7 years ago
Martin Atkins	9a62ab3014	command: "terraform show" renders plans like "terraform plan" ... During the Terraform 0.12 work we briefly had a partial update of the old Terraform 0.11 (and prior) diff renderer that could work with the new plan structure, but could produce only partial results. We switched to the new plan implementation prior to release, but the "terraform show" command was left calling into the old partial implementation, and thus produced incomplete results when rendering a saved plan. Here we instead use the plan rendering logic from the "terraform plan" command, making the output of both identical. Unfortunately, due to the current backend architecture that logic lives inside the local backend package, and it contains some business logic around state and schema wrangling that would make it inappropriate to move wholesale into the command/format package. To allow for a low-risk fix to the "terraform show" output, here we avoid some more severe refactoring by just exporting the rendering functionality in a way that allows the "terraform show" command to call into it. In future we'd like to move all of the code that actually writes to the output into the "command" package so that the roles of these components are better segregated, but that is too big a change to block fixing this issue.	7 years ago
Radek Simko	7860f55e4f	Version tools per Go convention under tools.go	7 years ago
Martin Atkins	8664749b59	backend: Allow certain commands to opt out of required variable checks ... Terraform Core expects all variables to be set, but for some ancillary commands it's fine for them to just be set to placeholders because the variable values themselves are not key to the command's functionality as long as the terraform.Context is still self-consistent. For such commands, rather than prompting for interactive input for required variables we'll just stub them out as unknowns to reflect that they are placeholders for values that a user would normally need to provide. This achieves a similar effect to how these commands behaved before, but without the tendency to produce a slightly invalid terraform.Context that would fail in strange ways when asked to run certain operations.	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
Martin Atkins	7e29b9b5d4	core: Warn when creating and applying with -target ... The documentation for the -target option warns that it's intended for exceptional circumstances only and not for routine use, but that's not a very prominent location for that warning and so some users miss it. Here we make the warning more prominent by including it directly in the Terraform output when -target is in use. We first warn during planning that the plan might be incomplete, and then warn again after apply concludes and direct the user to run "terraform plan" to make sure that there are no further changes outstanding. The latter message is intended to reinforce that -target should only be a one-off operation and that you should always run without it soon after to ensure that the workspace is left in a consistent, converged state.	7 years ago
Pam Selle	9631e4c73d	Merge pull request #20571 from sergkondr/fix_misspelling ... fix misspelling	7 years ago
Radek Simko	5b9f2fafc8	Standardise directory name for test data	7 years ago
Martin Atkins	b1213f7f6c	backend/local: don't panic when an instance has only a deposed object ... This unusual situation isn't supposed to arise in normal use, but it can come up in practice in some edge-case scenarios where Terraform fails in a severe way during a create_before_destroy. Some earlier versions of Terraform also had bugs in their handling of deposed objects, so this may also arise if upgrading from one of those older versions with some leftover deposed objects in the state.	7 years ago
Radek Simko	8a6d1d62b6	stringer: Regenerate files with latest version	7 years ago
Sander van Harmelen	57f6e01830	backend/local: preserve serial and lineage on failure ... When failing to write the state, the local backend writes the state to a local file called `errrored.tfstate`. Previously it would do so by creating a new state file which would use a new serial and lineage. By exorting the existing state file and directly assigning the new state, the serial and lineage are preserved.	7 years ago
Sander van Harmelen	973e2a7cf9	core: add a context to the UIInput interface	7 years ago
Kristin Laemmert	b9d8e96e0c	command/plan: plan output should indicate if a resource is being (#20580) ... replaced because the instance was tainted.	7 years ago
Sergey Kondrashov	43e7a7b552	fix misspelling	7 years ago
James Bardin	c814f2da37	Change backend.ValidateConfig to PrepareConfig ... This mirrors the change made for providers, so that default values can be inserted into the config by the backend implementation. This is only the interface and method name changes, it does not yet add any default values.	7 years ago
James Bardin	6cc3e1d0bd	move init error to where it is generated ... The init error was output deep in the backend by detecting a special ResourceProviderError and formatted directly to the CLI. Create some Diagnostics closer to where the problem is detected, and passed that back through the normal diagnostic flow. While the output isn't as nice yet, this restores the helpful error message and makes the code easier to maintain. Better formatting can be handled later.	7 years ago
Martin Atkins	e3618f915b	backend/local: Fix mock provider in tests ... We've changed the contract for PlanResourceChange to now require the provider to populate any default values (including unknowns) it wants to set for computed arguments, so our mock provider here now needs to be a little more complex to deal with that. This fixes several of the tests in this package. A minor change to TestLocal_applyEmptyDirDestroy was required to make it properly configure the mock provider so PlanResourceChange can access the schema.	7 years ago
Martin Atkins	0c0a437bcb	Move module install functionality over to internal/initwd	7 years ago
Radek Simko	f64978b64c	backend/local: Render CBD replacement (+/-) correctly (#19642) ... * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function	7 years ago
Radek Simko	3ab4739ba4	backend/local: Avoid rendering data sources on destroy	7 years ago
Radek Simko	e55079abc9	backend/local: Fix incorrect destroy/update count on apply	7 years ago
Kristin Laemmert	67aa944166	backend/local: decode variables with cty.DynamicPseudoType ... Variables values are marshalled with an explicit type of cty.DynamicPseudoType, but were being decoded using `Implied Type` to try and guess the type. This was causing errors because `Implied Type` does not expect to find a late-bound value.	7 years ago
Martin Atkins	12572e97bc	core: Automatically upgrade resource instance states on read ... If an instance object in state has an earlier schema version number then it is likely that the schema we're holding won't be able to decode the raw data that is stored. Instead, we must ask the provider to upgrade it for us first, which might also include translating it from flatmap form if it was last updated with a Terraform version earlier than v0.12. This ends up being a "seam" between our use of int64 for schema versions in the providers package and uint64 everywhere else. We intend to standardize on int64 everywhere eventually, but for now this remains consistent with existing usage in each layer to keep the type conversion noise contained here and avoid mass-updates to other Terraform components at this time. This also includes a minor change to the test helpers for the backend/local package, which were inexplicably setting a SchemaVersion of 1 on the basic test state but setting the mock schema version to zero, creating an invalid situation where the state would need to be downgraded.	7 years ago
Sander van Harmelen	4c878db8fd	Merge pull request #19464 from hashicorp/svh/f-context ... backend/remote: implement the Local interface	8 years ago
Martin Atkins	168d84b3c4	core: Make resource type schema versions visible to callers ... Previously we were fetching these from the provider but then immediately discarding the version numbers because the schema API had nowhere to put them. To avoid a late-breaking change to the internal structure of terraform.ProviderSchema (which is constructed directly all over the tests) we're retaining the resource type schemas in a new map alongside the existing one with the same keys, rather than just switching to using the providers.Schema struct directly there. The methods that return resource type schemas now return two arguments, intentionally creating a little API friction here so each new caller can be reminded to think about whether they need to do something with the schema version, though it can be ignored by many callers. Since this was a breaking change to the Schemas API anyway, this also fixes another API wart where there was a separate method for fetching managed vs. data resource types and thus every caller ended up having a switch statement on "mode". Now we just accept mode as an argument and do the switch statement within the single SchemaForResourceType method.	8 years ago
Sander van Harmelen	35d9ce3f92	backend/remote: implement the Local interface	8 years ago
Sander van Harmelen	a17f317025	Change how to fall back from remote to local backend ... In order to support free organizations, we need a way to load the `remote` backend and then, depending on the used offering/plan, enable or disable remote operations. In other words, we should be able to dynamically fall back to the `local` backend if needed, after first configuring the `remote` backend. To make this works we need to change the way this was done previously when the env var `TF_FORCE_LOCAL_BACKEND` was set. The clear difference of course being that the env var would be available on startup, while the used offering/plan is only known after being able to connect to TFE.	8 years ago
Martin Atkins	27abd9c6b8	command: Fix TestMetaBackend_localDoesNotDeleteLocal ... The changes to how we handle setting the state path on the local backend broke the heuristic we were using here for detecting migration from one local backend to another with the same state path, which would by default end up deleting the state altogether after migration. We now use the StatePaths method to do this, which takes into account both the default values and any settings that have been set. Additionally this addresses a flaw in the old method which could potentially have deleted all non-default workspace state files if the "path" setting were changed without also changing the "workspace_dir" setting. This new approach is conservative because it will preserve all of the files if any one overlaps.	8 years ago
Martin Atkins	ec27526cc3	command: Fix TestMetaBackend_configuredChangeCopy_multiToMulti ... This was failing because we now handle the settings for the local backend a little differently as a result of decoding it with the HCL2 machinery. Specifically, the backend.State* fields are now assumed to be what is given in configuration, and any CLI overrides are maintained separately in OverrideState* fields so that they can be imposed "just in time" in StatePaths. This is particularly important because OverrideStatePath (when set) is used regardless of workspace name, while StatePath is a suitable value only for the "default" workspace, with others needing to be constructed from StateWorkspaceDir instead.	8 years ago
Sander van Harmelen	52a1b22f7a	Implement the remote enhanced backend ... This is a refactored version of the `remote` backend that was initially added to Terraform v0.11.8 which should now be compatible with v0.12.0.	8 years ago
Sander van Harmelen	b846c5f653	Make the test compile again ... Not sure if these checks still make sense, but without this change the test don’t compile for the related packages.	8 years ago
Sander van Harmelen	48ef7ecfa6	Updates after running `make fmt` with Go v1.11.1	8 years ago
James Bardin	0a0eece15c	add backend cli options after configuration ... The cli should override the config	8 years ago
Martin Atkins	541952bb8f	Revert some work that happened since v0.12-dev branched ... This work was done against APIs that were already changed in the branch before work began, and so it doesn't apply to the v0.12 development work. To allow v0.12 to merge down to master, we'll revert this work out for now and then re-introduce equivalent functionality in later commits that works against the new APIs.	8 years ago
Martin Atkins	98bbd560b5	command: Fix most (but not all) "terraform plan" tests	8 years ago
Martin Atkins	741d334ee4	command: Even more fixes for "apply" command tests	8 years ago
Martin Atkins	c5940f2438	backend/local: Increase log verbosity for backend context construction ... There are several steps here and a number of them can include reaching out to remote servers or executing local processes, so it's helpful to have some trace logs to better narrow down causes of errors and hangs during this step.	8 years ago
Martin Atkins	a6f399517b	backend/local: reinstate additional steps in plan file processing ... In earlier refactoring we skipped implementing prior state safety checks, propagating the target addresses from plan, and verifying that all of the providers are exactly the same from the plan being created. This change reinstates those checks, including a new error message for the "stale plan" situation.	8 years ago
Martin Atkins	91d2de6a25	backend/local: Stub out remaining planfile todos with errors ... This is just to make sure they show up later when we are working on the tests, so we can be sure not to forget to address them.	8 years ago
Martin Atkins	fa3b4fc9de	backend/local: Populate changes into a context built from planfile	8 years ago
Martin Atkins	cbc548eb36	command: Do CLI init of backend loaded from plan ... If we don't do this, we can't produce any output when applying a saved plan file. Here we also introduce a check to the local backend's ReportResult function so that it won't panic if CLI init is skipped, although that will no longer happen in the apply-from-file case due to the change described in the previous paragraph.	8 years ago
Martin Atkins	2b80df0163	backend/local: Require caller to set PlanOutBackend with PlanOutPath ... We can't generate a valid plan file without a backend configuration to write into it, but it's the responsibility of the caller (the command package) to manage the backend configuration mechanism, so we require it to tell us what to write here. This feels a little strange because the backend in principle knows its own config, but in practice the backend only knows the _processed_ version of the config, not the raw configuration value that was used to configure it.	8 years ago