9 Commits (6dcf00aefc56b48bae54822a6e62eacffd2bc3ea)

Author	SHA1	Message	Date
Martin Atkins	bdc5f152d7	refactoring: Implied move statements can be cross-package ... Terraform uses "implied" move statements to represent the situation where it automatically handles a switch from count to no-count on a resource. Because that situation requires targeting only a specific resource instance inside a specific module instance, implied move statements are always presented as if they had been declared in the root module and then traversed through the exact module instance path to reach the target resource. However, that means they can potentially cross a module package boundary, if the changed resource belongs to an external module. Normally we prohibit that to avoid the root module depending on implementation details of the called module, but Terraform generates these implied statements based only on information in the called module and so there's no need to apply that same restriction to implied move statements, which will always have source and destination addresses belonging to the same module instance. This change therefore fixes a misbehavior where Terraform would reject an attempt to switch from no-count to count in a called module, where previously the author of the calling configuration had no recourse to fix it because the change has actually happened upstream.	4 years ago
James Bardin	f46cf7b8bc	cleanup some move graph handling ... Create a separate `validateMoveStatementGraph` function so that `ValidateMoves` and `ApplyMoves` both check the same conditions. Since we're not using the builtin `graph.Validate` method, because we may have multiple roots and want better cycle diagnostics, we need to add checks for self references too. While multiple roots are an error enforced by `Validate` for the concurrent walk, they are OK when using `TransitiveReduction` and `ReverseDepthFirstWalk`, so we can skip that check. Apply moves must first use `TransitiveReduction` to reduce the graph, otherwise nodes may be skipped if they are passed over by a transitive edge.	4 years ago
Katy Moe	aeecc6a627	add AffectedAbsResource to interface	4 years ago
Katy Moe	11566b1d11	introduce AbsMoveableResource ... AbsMoveableResource is an AbsMoveable that is either a resource or a resource instance. This interface represents a moveable that has a resource type.	4 years ago
Katy Moe	7162e79fdf	return error on resource type mismatch ... A resource move is invalid if the two resource( instance)s are of different resource types. Check for this during move validation.	4 years ago
Katy Moe	4305271cff	remove occurrences of AbsMovable	4 years ago
Martin Atkins	aa414f3ab3	refactoring: First round of ValidateMoves rules ... This is a first pass at implementing refactoring.ValidateMoves, covering the main validation rules. This is not yet complete. A couple situations not yet covered are represented by commented test cases in TestValidateMoves, although that isn't necessarily comprehensive. We'll do a further pass of filling this out with any other subtleties before we ship this feature.	5 years ago
Martin Atkins	f76a3467dc	core: Call into refactoring.ValidateMoves after creating a plan ... As of this commit, refactoring.ValidateMoves doesn't actually do anything yet (always returns nil) but the goal here is to wire in the set of all declared instances so that refactoring.ValidateMoves will then have all of the information it needs to encapsulate our validation rules. The actual implementation of refactoring.ValidateMoves will follow in subsequent commits.	5 years ago
Martin Atkins	3e5bfa7364	refactoring: Stubbing of the logic for handling moves ... This is a whole lot of nothing right now, just stubbing out some control flow that ultimately just leads to TODOs that cause it to do nothing at all. My intent here is to get this cross-cutting skeleton in place and thus make it easier for us to collaborate on adding the meat to it, so that it's more likely we can work on different parts separately and still get a result that tessellates.	5 years ago