53 Commits (b41f08d79d2a2e8dea1fa690c19bb6dff249e141)

Author	SHA1	Message	Date
Sander van Harmelen	67db9da000	Add checks for all flags we currently don’t support ... For Plan only: -module-depth=n For Plan & Apply -parallelism=m -refresh=false -var “foo=bar” and -var-file=foo	8 years ago
Sander van Harmelen	1696ade924	backend/migrations: check all workspaces ... This commit fixes a bug that (in the case of the `local` backend) would only check if the selected workspace had a state when deciding to preform a migration. When the selected workspace didn’t have a state (but other existing workspace(s) did), the migration would not be preformed and the other workspaces would be ignored.	8 years ago
Sander van Harmelen	495d1ea350	Use New() instead of `once.Do(b.init)`	8 years ago
Sander van Harmelen	97d1c46602	Update the backend import names ... It’s a purely cosmetic change, but I find it easier to read them like this.	8 years ago
Kristin Laemmert	b8a1a77f6b	command: fix spelling in error message - fixes #18065 (#18241)	8 years ago
James Bardin	bdd475e149	use the new clistate.Locker in commands ... Use the new StateLocker field to provide a wrapper for locking the state during terraform.Context creation in the commands that directly manipulate the state.	8 years ago
James Bardin	e9a76808df	create clistate.Locker interface ... Simplify the use of clistate.Lock by creating a clistate.Locker instance, which stores the context of locking a state, to allow unlock to be called without knowledge of how the state was locked. This alows the backend code to bring the needed UI methods to the point where the state is locked, and still unlock the state from an outer scope. Provide a NoopLocker as well, so that callers can always call Unlock without verifying the status of the lock. Add the StateLocker field to the backend.Operation, so that the state lock can be carried between the different function scopes of the backend code. This will allow the backend context to lock the state before it's read, while allowing the different operations to unlock the state when they complete.	8 years ago
Masayuki Morita	f440dba137	Standardize on log level "WARN" rather than "WARNING"	8 years ago
James Bardin	f45205feb7	re-word state migration prompts ... The existing prompts were worded as if backend configurations were named, but they can only really be referenced by their type. Change the wording to reference them as type "X backend". When migrating state, refer to the backends as the "previously configured" and "newly configured", since they will often have the same type.	8 years ago
James Bardin	7c93b2e5e6	remove duplicate backend migration prompts ... The duplicate prompts can be confusing when the user confirms that a migration should happen and we immediately prompt a second time for the same thing with slightly different wording. The extra hand-holding that this provides for legacy remote states is less critical now, since it's been 2 major release cycles since those were removed.	8 years ago
Martin Atkins	0fe43c8977	cli: allow disabling "next steps" message in terraform plan ... In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.	9 years ago
David Glasser	039d36bf91	command: add "apply -auto-approve=false" flag ... A common reason to want to use `terraform plan` is to have a chance to review and confirm a plan before running it. If in fact that is the only reason you are running plan, this new `terraform apply -auto-approve=false` flag provides an easier alternative to P=$(mktemp -t plan) terraform refresh terraform plan -refresh=false -out=$P terraform apply $P rm $P The flag defaults to true for now, but in a future version of Terraform it will default to false.	9 years ago
Patrick Aikens	7775ef809b	Display correct to and from backends in copy message when migrating to new remote state (#15318)	9 years ago
James Bardin	6728c48d8c	fix whitespace around backend init success message ... make it better match the surrounding messages.	9 years ago
Martin Atkins	f7ce6a15f8	backend: Operation.Environment renamed to "Workspace" ... This is part of an effort to switch this terminology across all of Terraform.	9 years ago
Martin Atkins	418a8a8bc9	command + backend: rename various API objects to "Workspace" terminology ... We're shifting terminology from "environment" to "workspace". This takes care of some of the main internal API surface that was using the old terminology, though is not intended to be entirely comprehensive and is mainly just to minimize the amount of confusion for maintainers as we continue moving towards eliminating the old terminology.	9 years ago
Martin Atkins	5f9f13ab8f	command: show warnings from backend config validation ... Previously we just silently ignored warnings from validating the backend config, but now that we have a deprecated argument it's important to print these out so users can respond to the deprecation warning.	9 years ago
James Bardin	718ede0636	have Meta.Backend use a Config rather than loading ... Instead of providing the a path in BackendOpts, provide a loaded *config.Config instead. This reduces the number of places where configuration is loaded.	9 years ago
David Glasser	783908ee25	core: fix bad Sprintf in backend migration message (#14601) ... Before this, invoking this codepath would print Terraform has successfully migrated from legacy remote state to your configured remote state.%!(EXTRA string=s3)	9 years ago
Edward Betts	be265479a9	correct spelling mistakes (#13979)	9 years ago
James Bardin	7aa2ce8341	add -reconfigure option for init ... The reconfigure flag will force init to ignore any saved backend state. This is useful when a user does not want any backend migration to happen, or if the saved configuration can't be loaded at all for some reason.	9 years ago
James Bardin	d059939f88	Merge pull request #13262 from hashicorp/jbardin/lock-timeouts ... lock timeouts	9 years ago
James Bardin	5eca913b14	add cli flags for -lock-timeout ... Add the -lock-timeout flag to the appropriate commands. Add the -lock flag to `init` and `import` which were missing it. Set both stateLock and stateLockTimeout in Meta.flagsSet, and remove the extra references for clarity.	9 years ago
James Bardin	305ef43aa6	provide contexts to clistate.Lock calls ... Add fields required to create an appropriate context for all calls to clistate.Lock. Add missing checks for Meta.stateLock, where we would attempt to lock, even if locking should be skipped.	9 years ago
James Bardin	3f0dcd1308	Have the clistate Lock use LockWithContext ... - Have the ui Lock helper use state.LockWithContext. - Rename the message package to clistate, since that's how it's imported everywhere. - Use a more idiomatic placement of the Context in the LockWithContext args.	9 years ago
James Bardin	8050eda52d	don't delete local state on a local backend ... Don't erase local state during backend migration if the new and old paths are the same. Skipping the confirmation and copy are handled in another patch, but the local state was always erased by default, even when it was our new state.	9 years ago
James Bardin	c891ab50b7	detect when backend.Hash needs update ... It's possible to not change the backend config, but require updating the stored backend state by moving init options from the config file to the `-backend-config` flag. If the config is the same, but the hash doesn't match, update the stored state.	9 years ago
James Bardin	ff2d753062	add Rehash to terraform.BackendState ... This method mirrors that of config.Backend, so we can compare the configration of a backend read from a config vs that of a backend read from a state. This will prevent init from reinitializing when using `-backend-config` options that match the existing state.	9 years ago
James Bardin	8027fe9e08	Don't Validate if we have an execution plan ... The plan file should contain all data required to execute the apply operation. Validation requires interpolation, and the `file()` interpolation function may fail if the module files are not present. This is the case currently with how TFE executes plans.	9 years ago
James Bardin	54e536cfe0	add `-force-copy` option to init command ... The `-force-copy` option will suppress confirmation for copying state data. Modify some tests to use the option, making sure to leave coverage of the Input code path.	9 years ago
Mitchell Hashimoto	4f59576231	command: fix awkward wording in message	9 years ago
Mitchell Hashimoto	96e38041ab	command: use backendinit instead of initializing legacy directly ... Fixes #12806 This should've been part of 2c19aa69d9 This is the same issue, just missed a spot. Tests are hard to cover for this since we're removing the legacy backends one by one, eventually it'll be gone. A good sign is that we don't import backendlegacy at all anymore in command/	9 years ago
Mitchell Hashimoto	df8529719c	command/init: backend-config accepts key=value pairs ... This augments backend-config to also accept key=value pairs. This should make Terraform easier to script rather than having to generate a JSON file. You must still specify the backend type as a minimal amount in configurations, example: ``` terraform { backend "consul" {} } ``` This is required because Terraform needs to be able to detect the _absense_ of that value for unsetting, if that is necessary at some point.	9 years ago
Mitchell Hashimoto	e1f4eca93c	command: apply needs to look at the right field for backend state ... Plans were properly encoding backend configuration but the apply was reading it from the wrong field. :( This meant that every apply from a plan was applying it locally with backends. This needs to get released ASAP.	9 years ago
Mitchell Hashimoto	81639480fb	command: recompute config hash with ConfigFile set ... Fixes #12749 If we merge in an extra partial config we need to recompute the hash to compare with the old value to detect that change. This hash needs to NOT be stored and just used as a temporary. We want to keep the original hash in the state so that we don't detect a change from the config (since the config will always be partial).	9 years ago
Mitchell Hashimoto	8b208a597d	command/push: don't allow pushing with local backend	9 years ago
Mitchell Hashimoto	03493f7d46	command: validate backend config ... The validation itself was added a couple weeks ago but I forgot to actually call it. :sad:	9 years ago
Mitchell Hashimoto	bdde7d845a	Merge pull request #12347 from hashicorp/b-env-migrate ... command: migrating envs when changing backends	9 years ago
Mitchell Hashimoto	549d525487	Merge pull request #12320 from hashicorp/b-legacy-state ... command: fix loading legacy remote state + migration guide	9 years ago
Mitchell Hashimoto	1d8b76c89d	command: initial work on migrating envs, basic cases first	9 years ago
Mitchell Hashimoto	2c19aa69d9	command: legacy remote state should load from backendinit	9 years ago
James Bardin	b53704ed87	Thread the environment through all commands ... Add Env and SetEnv methods to command.Meta to retrieve the current environment name inside any command. Make sure all calls to Backend.State contain an environment name, and make the package compile against the update backend package.	9 years ago
James Bardin	1ea9413c07	Remove state path handling from commands ... The Local backend is now responsible for handling the paths to the local state files, since they are dependent on the current environment.	9 years ago
Mitchell Hashimoto	3cedfa00f4	command: use backend.CLIIinit ... I made this interface way back with the original backend work and I guess I forgot to hook it up! This is becoming an issue as I'm working on our 2nd enhanced backend that requires this information and I realized it was hardcoded before. This propertly uses the CLIInit interface allowing any backend to gain access to this data.	9 years ago
Mitchell Hashimoto	478a7dbfe7	command: convert to using backend/init	9 years ago
James Bardin	5095d7c6a7	Add complete unlock test ... Test actual unlock failure and success through the the unlock command.	9 years ago
James Bardin	f5ed8cd288	Use NewLockInfo to get a pre-populated value ... Using NewLockInfo ensure we start with all required fields filled.	9 years ago
James Bardin	4f0c465187	make command tests pass with new state.Locker	9 years ago
Mitchell Hashimoto	90f3d40c1f	command: use new state lock/unlock helpers for better UX	9 years ago
George Hartzell	e39f4e1993	Typo: determien -> determine (#11888)	9 years ago