18 Commits (f-langserver)

Author	SHA1	Message	Date
Pam Selle	e4d2469698	Update comment	6 years ago
Pam Selle	de953eca6f	Fixup for allowing empty lists/sets of resources	6 years ago
Pam Selle	19b408e053	Only need this one call, don't call the meta func	6 years ago
Pam Selle	61ce1cb3ad	Fix provider related tests	6 years ago
Pam Selle	01da7b4f7f	Tested and confirmed we cannot delete this, so removed TODO	6 years ago
Pam Selle	87fdcd0064	Add a new method cause doing things in module is weird	6 years ago
Pam Selle	3b4382082d	More comments and names	6 years ago
Pam Selle	fd34def9dc	More comment updates, a lil refactor	6 years ago
Pam Selle	9482bb8eb0	Comment cleanup	6 years ago
Pam Selle	d144b83d50	This works, with lots of noise	6 years ago
Martin Atkins	66f96cf842	command: Un-stub and reimplement "terraform state rm" ... This was previously targeting the old state manager and state types, so it needed some considerable rework to get it working again with the new state types. Since our new resource address syntax lacks the weird extra .deposed special case we had before, we instead interpret addresses as whole-instance addresses here and remove the deposed objects along with the current one (if present), since this is more likely to match with user expectations because we don't consider deposed objects to be independently addressable in any other situation. With that said, to be more explicit about what is going on we do now have a -dry-run mode and maintain separate counts of current and deposed instances so that we can expose that in the UI where relevant.	8 years ago
Martin Atkins	ec2e6cb06f	terraform: Prune resource husks at the end of "terraform destroy" ... When we're being asked to destroy everything, we ideally want to end up with a totally empty state. Normally we will conservatively keep around the "husks" of resources (what's left after all of the instances have been destroyed) unless they are configured without count or for_each, but in this special case we'll prune those out. The implication of this is that in "weird" expression contexts that happen before the next "terraform plan", such as evaluation in "terraform console" or expressions in data resources and provider blocks that get evaluated during the refresh walk, we will see these results as unknown rather than as empty lists of objects. We accept that weirdness for now because in a future release we are likely to remove "refresh" as a separate walk anyway, doing all of that work during the plan walk where we can ensure that these values are properly re-populated before trying to use them.	8 years ago
Martin Atkins	faddb83a92	core: If create leg of create_before_destroy fails, restore deposed ... I misunderstood the logic here on the first pass of porting to the new provider and state types: EvalUndeposeState is supposed to return the deposed object back to being current again, so we can undo the deposing in the case where the create leg fails. If we don't do this, we end up leaving the instance with no current object at all and with its prior object deposed, and then the later destroy node deletes that deposed object, leaving the user with no object at all. For safety we skip this restoration if there _is_ a new current object, since a failed create can still produce a partial result which we need to keep to avoid losing track of any remote objects that were successfully created.	8 years ago
Martin Atkins	334c6f1c2c	core: Be more explicit in how we handle create_before_destroy ... Previously our handling of create_before_destroy -- and of deposed objects in particular -- was rather "implicit" and spread over various different subsystems. We'd quietly just destroy every deposed object during a destroy operation, without any user-visible plan to do so. Here we make things more explicit by tracking each deposed object individually by its pseudorandomly-allocated key. There are two different mechanisms at play here, building on the same concepts: - During a replace operation with create_before_destroy, we *pre-allocate* a DeposedKey to use for the prior object in the "apply" node and then pass that exact id to the destroy node, ensuring that we only destroy the single object we planned to destroy. In the happy path here the user never actually sees the allocated deposed key because we use it and then immediately destroy it within the same operation. However, that destroy may fail, which brings us to the second mechanism: - If any deposed objects are already present in state during _plan_, we insert a destroy change for them into the plan so that it's explicit to the user that we are going to destroy these additional objects, and then create an individual graph node for each one in DiffTransformer. The main motivation here is to be more careful in how we handle these destroys so that from a user's standpoint we never destroy something without the user knowing about it ahead of time. However, this new organization also hopefully makes the code itself a little easier to follow because the connection between the create and destroy steps of a Replace is reprseented in a single place (in DiffTransformer) and deposed instances each have their own explicit graph node rather than being secretly handled as part of the main instance-level graph node.	8 years ago
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	424afe0ace	states: separate types for encoded and decoded state objects ... The types here were originally written to allow us to defer decoding of object values until schemas are available, but it turns out that this was forcing us to defer decoding longer than necessary and potentially decode the same value multiple times. To avoid this, we create pairs of types to represent the encoded and decoded versions and methods for moving between them. These types are identical to one another apart from how the dynamic values are represented.	8 years ago
Martin Atkins	a33f941778	states: New SyncState type ... This is a wrapper around State that is able to perform higher-level manipulations (at the granularity of the entire state) in a concurrency-safe manner, using the lower-level APIs exposed by State and all of the types it contains. The granularity of a SyncState operation roughly matches the granularity off a state-related EvalNode in the "terraform" package, performing a sequence of more primitive operations while guaranteeing atomicity of the entire change. As a compromise for convenience of usage, it's still possible to access the individual state data objects via this API, but they are always copied before returning to ensure that two distinct callers cannot have data races. Callers should access the most granular object possible for their operation.	8 years ago
Martin Atkins	b975ada8db	states: New package with modern models for Terraform state ... Our previous state models in the "terraform" package had a few limitations that are addressed here: - Instance attributes were stored as map[string]string with dot-separated keys representing traversals through a data structure. Now that we have a full type system, it's preferable to store it as a real data structure. - The existing state structures skipped over the "resource" concept and went straight to resource instance, requiring heuristics to decide whether a particular resource should appear as a single object or as a list of objects when used in configuration expressions. - Related to the previous point, the state models also used incorrect terminology where "ResourceState" was really a resource instance state and "InstanceState" was really the state of a particular remote object associated with an instance. These new models use the correct names for each of these, introducing the idea of a "ResourceInstanceObject" as the local record of a remote object associated with an instance. This is a first pass at fleshing out a new model for state. Undoubtedly there will be further iterations of this as we work on integrating these new models into the "terraform" package. These new model types no longer serve double-duty as a description of the JSON state file format, since they are for in-memory use only. A subsequent commit will introduce a separate package that deals with persisting state to files and reloading those files later.	8 years ago