17 Commits (ba7679b6791a306a73062ddd5a00359452e152fc)

Author	SHA1	Message	Date
Martin Atkins	a3403f2766	terraform: Ugly huge change to weave in new State and Plan types ... Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.	8 years ago
Martin Atkins	c937c06a03	terraform: ugly huge change to weave in new HCL2-oriented types ... Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.	8 years ago
Martin Atkins	5782357c28	backend: Update interface and implementations for new config loader ... The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".	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
James Bardin	ef8ed1e275	coalesce the backened interrupt code ... Moves the nested select statements for backend operations into a single function. The only difference in this part was that apply called PersistState, which should be harmless regardless of the type of operation being run.	8 years ago
James Bardin	7cba68326a	always wait for a RunningOperation to return ... If the user wishes to interrupt the running operation, only the first interrupt was communicated to the operation by canceling the provided context. A second interrupt would start the shutdown process, but not communicate this to the running operation. This order of event could cause partial writes of state. What would happen is that once the command returns, the plugin system would stop the provider processes. Once the provider processes dies, all pending Eval operations would return return with an error, and quickly cause the operation to complete. Since the backend code didn't know that the process was shutting down imminently, it would continue by attempting to write out the last known state. Under the right conditions, the process would exit part way through the writing of the state file. Add Stop and Cancel CancelFuncs to the RunningOperation, to allow it to easily differentiate between the two signals. The backend will then be able to detect a shutdown and abort more gracefully. In order to ensure that the backend is not in the process of writing the state out, the command will always attempt to wait for the process to complete after cancellation.	8 years ago
Stefan Schmidt	c200c170ad	Handle refresh errors.	8 years ago
James Bardin	85295e5c23	watch for cancellation in plan and refresh ... Cancellation in the local backend was only implemented for apply.	8 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
Mitchell Hashimoto	2be1f55cbb	backend/local: allow refresh on empty/non-existent state ... This allows a refresh on a non-existent or empty state file. We changed this in 0.9.0 to error which seemed reasonable but it turns out this complicates automation that runs refresh since it now needed to determine if the state file was empty before running. Its easier to just revert this into a warning with exit code zero. The reason this changed is because in 0.8.x and earlier, the output would be simply empty with exit code zero which seemed odd.	9 years ago
Mitchell Hashimoto	9574f16f92	backend/local: refresh with no config should not crash on input ... Fixes #12174 You're allowed to refresh with a nil module (no configs) as long as you have state. However, if `-input=true` (default) then this would crash since the input attempts to read the configs. The API contract with `terraform.Context` says that the module tree must be non-nil and loaded. To do this for other commands we create an empty module tree. We do that here now.	9 years ago
James Bardin	f2e496a14c	Have backend operations properly unlock state ... Make sure unlock is called with the correct LockID during operations	9 years ago
James Bardin	67dc16c9ca	Make backend/local test pass	9 years ago
Mitchell Hashimoto	65982bd412	backend/local: use new command/state package for better UX	9 years ago
James Bardin	9cdba1f199	enable local state locking for apply ... Have the LocalBackend lock the state during operations, and enble this for the apply comand.	9 years ago
Mitchell Hashimoto	397e1b3132	backend/local ... The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.	9 years ago