13 Commits (6440c839474f052d8997bb5cec19c2743e5108e6)

Author	SHA1	Message	Date
Alisdair McDiarmid	e02e53ed4d	states: Add roundtrip v3->v4 with builtin provider	6 years ago
Kristin Laemmert	58bcc2e9bb	addrs: detect builtin provider when parsing legacy provider string (#25154) ... * addrs: detect builtin provider when parsing legacy provider string The ParseLegacyAbsProviderConfig was not detecting builtin providers ("terraform"), which caused issues for all users with 0.12 state and the "terraform_remote_state" data source. Since "terraform" is the only built-in provider this adds a very simple check to the parser so it properly returns the builtin FQN. * add tests to the addrs package	6 years ago
James Bardin	9fe87fe520	remove unused depends_on field and add test ... The depends_on fields was deprecated during 0.12, and is no longer used. Add a roundtrip test for the create_before_destroy status.	6 years ago
Kristin Laemmert	d95667f264	states/version3 upgrade: revert provider FQN changes (#24504) ... This commit reverts an earlier change which automatically converted provider strings to legacy provider FQNs. It has become apparent that a state upgrade step will be required before upgrading to v0.13.	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
Martin Atkins	1ae47ae314	states/statefile: tolerate and ignore invalid depends_on in version 3 ... The state refactoring command "terraform state mv" in Terraform 0.11 does not update existing dependency addresses recorded in the state when it moves objects around, and Terraform only updates the dependency addresses in the state when it performs a full update on a resource instance, and so it's a common problem for folks updating from Terraform 0.11 with resource names that are not valid identifiers to run into state upgrade errors even though they have followed the instructions produced by "terraform 0.12checklist". Dependencies are synced from config during every refresh walk anyway, so in practice we can get away with just discarding invalid dependency addresses and letting the refresh walk update them. In practice these addresses are unlikely to be pointing at a resource that actually exists anyway, because if so Terraform 0.12's configuration parser wouldn't be able to interpret it. Discarding invalid dependency addresses allows the state upgrade to complete successfully in such cases and thus gives the refresh step an opportunity to repair the problem.	7 years ago
James Bardin	5a0a0020a0	read+write the new dependencies in the statefile ... The test fixture did not like having modules when using the generic json map, so read and compare the states in the final *File datastructure.	7 years ago
Radek Simko	95cbf1c282	Fix copy-paste errors in test data	7 years ago
Masayuki Morita	ac83827c90	states/statefile: decode backend hash as uint64 ... Fixes #21478 In #19688, `terraform.BackendState.Hash` was fixed. We also need to fix `states/statefile.backendStateV2.Hash`	7 years ago
Kristin Laemmert	d7dda4e436	states/statefile: upgrade legacy dependency syntax (#21159) ... We used to allow "foo.1" etc as a reference, but now it's "foo[1]".	7 years ago
Sander van Harmelen	634430ebb2	Fix wildcard dependencies when upgrading states ... Fixes #19347	8 years ago
Martin Atkins	fb57801dfe	states: object Private data is []byte, not cty.Value ... We're going to allow the provider to encode whatever it wants in here, so a provider can use whatever is most convenient for its implementation language and to avoid some of the bugs we saw with the prior model where the forced round-trip through JSON and back into interface{} would cause some loss of fidelity, leading to bugs.	8 years ago
Martin Atkins	5c1c6e9d9c	statefile: New package for loading and saving state files ... Whereas the parent directory "states" contains the models that represent state in memory, this package's responsibility is in serializing a subset of that data to a JSON-based file format and then reloading that data back into memory later. For reading, this package supports state file formats going back to version 1, using lightly-adapted versions of the migration code previously used in the "terraform" package. State data is upgraded to the latest version step by step and then transformed into the in-memory state representation, which is distinct from any of the file format structs in this package to enable these to evolve separately. For writing, only the latest version (4) is supported, which is a new format that is a slightly-flattened version of the new in-memory state models introduced in the prior commit. This format retains the outputs from only the root module and it flattens out the module and instance parts of the hierarchy by including the identifiers for these inside the child object. The loader then reconstructs the multi-layer structure we use for more convenient access in memory. For now, the only testing in this package is of round-tripping different versions of state through a read and a write, ensuring the output is as desired. This exercises all of the reading, upgrading, and writing functions but should be augmented in later commits to improve coverage and introduce more focused tests for specific parts of the functionality.	8 years ago