Commit Graph

44 Commits

Author SHA1 Message Date
Dmitry Kisler
a127607a85
Rename terraform to tofu in GoString method and docstrings (#576)
Signed-off-by: Dmitry Kisler <admin@dkisler.com>
2023-09-26 19:09:27 +02:00
Elbaz
462c4667e0
OpenTofu rename - packages with tiny renames (#479) 2023-09-20 15:43:06 +03:00
Yaron Yarimi
c8acedd885
Rename github.com/placeholderplaceholderplaceholder/opentf to github.com/opentofu/opentofu (#461) 2023-09-20 14:35:35 +03:00
Marcin Wyszynski
5fa28ede2c
Adapt user-facing usages of terraform in internal/refactoring (#125) 2023-08-23 12:07:11 +02:00
Kuba Martin
ebcf7455eb
Rename root module name. (#4)
* Rename module name from "github.com/hashicorp/terraform" to "github.com/placeholderplaceholderplaceholder/opentf".

Signed-off-by: Jakub Martin <kubam@spacelift.io>

* Gofmt.

Signed-off-by: Jakub Martin <kubam@spacelift.io>

* Regenerate protobuf.

Signed-off-by: Jakub Martin <kubam@spacelift.io>

* Fix comments.

Signed-off-by: Jakub Martin <kubam@spacelift.io>

* Undo issue and pull request link changes.

Signed-off-by: Jakub Martin <kubam@spacelift.io>

* Undo comment changes.

Signed-off-by: Jakub Martin <kubam@spacelift.io>

* Fix comment.

Signed-off-by: Jakub Martin <kubam@spacelift.io>

* Undo some link changes.

Signed-off-by: Jakub Martin <kubam@spacelift.io>

* make generate && make protobuf

Signed-off-by: Jakub Martin <kubam@spacelift.io>

---------

Signed-off-by: Jakub Martin <kubam@spacelift.io>
2023-08-17 14:45:11 +02:00
James Bardin
ea1144995f update callers of InstallModules
Update callers of InstallModules and have `get` return only install
errors.
2023-08-07 15:22:02 -04:00
Liam Cervante
6882dd9530
testing framework: introduce test command optional flags (#33504)
* testing framework: introduce test command optional flags

* address consistency checks
2023-07-19 10:07:46 +02:00
hashicorp-copywrite[bot]
325d18262e [COMPLIANCE] Add Copyright and License Headers 2023-05-02 15:33:06 +00:00
Alisdair McDiarmid
8df065a2fe initwd: Switch from earlyconfig to configs
This is a mostly mechanical refactor with a handful of changes which
are necessary due to the semantic difference between earlyconfig and
configs.

When parsing root and descendant modules in the module installer, we now
check the core version requirements inline. If the Terraform version is
incompatible, we drop any other module loader diagnostics. This ensures
that future language additions don't clutter the output and confuse the
user.

We also add two new checks during the module load process:

* Don't try to load a module with a `nil` source address. This is a
  necessary change due to the move away from earlyconfig.

* Don't try to load a module with a blank name (i.e. `module ""`).
  Because our module loading manifest uses the stringified module path
  as its map key, this causes a collision with the root module, and a
  later panic. This is the bug which triggered this refactor in the
  first place.
2023-03-06 09:14:28 -05:00
kmoe
56a1e0d1c6
allow cross-package move statements (#31556) 2022-08-16 16:52:57 +02:00
James Bardin
e3ca4be4b9 goimports 2022-07-22 13:57:16 -04:00
James Bardin
dc9d7108dd use TopologicalOrder for evaluating moves
The dag package did not previously provide a topological walk of a given
graph. While the existing combination of a transitive reduction with a
depth-first walk appeared to accomplish this, depth-first is only
equivalent with a simple tree. If there are multiple paths to a node, a
depth-first approach will skip dependencies from alternate paths.
2022-07-22 13:57:16 -04:00
Radek Simko
7feef1c4aa
Use hashicorp/terraform-registry-address as a decoupled library (#28338)
* refactor: Use tfaddr for provider address parsing

* refactor: Use tfaddr for module address parsing

* deps: introduce hashicorp/terraform-registry-address
2022-07-08 14:46:29 +01:00
Martin Atkins
dc5964f8a3 refactoring: Use addrs.Map for maps with addresses as keys
We introduced the addrs.UniqueKey and addrs.UniqueKeyer mechanics as part
of implementing the ValidateMoves and ApplyMoves functions, as a way to
better encapsulate the solution to the problem that lots of our address
types aren't comparable and so cannot be used directly as map keys.

However, exposing addrs.UniqueKey handling directly in the logic adds
various noise to the algorithms and, in particular, obscures the fact that
MoveResults.Changes and MoveResult.Blocked both have different map key
types.

Here then we'll use the new addrs.Map helper type, which encapsulates the
idea of a map from an addrs.UniqueKeyer type to an arbitrary value type,
using the unique keys as the map keys internally. This does unfortunately
mean that we lose the conventional Go map access syntax and have to use
a method-based API instead, but I (subjectively) think that's an okay
compromise in return for avoiding the need to keep track inline of which
addrs.UniqueKey values correspond with which real addresses.

This is intended as an entirely-mechanical change, with equivalent
behavior to what it replaced. If anything here is doing something
materially different than what it replaced then that's a mistake.
2022-06-16 07:03:36 -07:00
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.
2022-01-11 08:43:57 -08:00
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.
2022-01-04 09:21:36 -05:00
James Bardin
22dc685052 check for nested module index changes
Changing only the index on a nested module will cause all nested moves
to create cycles, since their full addresses will match both the From
and To addresses. When building the dependency graph, check if the
parent is only changing the index of the containing module, and prevent
the backwards edge for the move.
2022-01-04 09:20:47 -05:00
James Bardin
deb82daf2b find implied moves in nested modules
Implied moves in nested modules were being skipped
2022-01-04 09:20:47 -05:00
Alisdair McDiarmid
d7ef123c12 refactoring: Move nested modules
When applying module `moved` statements by iterating through modules in
state, we previously required an exact match from the `moved`
statement's `from` field and the module address. This permitted moving
resources directly inside a module, but did not recur into module calls
within those moved modules.

This commit moves that exact match requirement so that it only applies
to `moved` statements targeting resources. In turn this allows nested
modules to be moved.
2021-12-21 16:25:06 -05:00
Katy Moe
aeecc6a627
add AffectedAbsResource to interface 2021-11-16 18:19:11 +00:00
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.
2021-11-15 11:05:33 +00:00
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.
2021-11-15 11:05:33 +00:00
Katy Moe
dc3ed6271c
add failing test for resource type mismatch 2021-11-15 11:05:33 +00:00
Katy Moe
4305271cff
remove occurrences of AbsMovable 2021-11-15 11:05:33 +00:00
kmoe
40ec62c139
command: make module installation interruptible
Earlier work to make "terraform init" interruptible made the getproviders
package context-aware in order to allow provider installation to be cancelled.

Here we make a similar change for module installation, which is now also
cancellable with SIGINT. This involves plumbing context through initwd and
getmodules. Functions which can make network requests now include a context
parameter whose cancellation cancels those requests.

Since the module installation code is shared, "terraform get" is now
also interruptible during module installation.
2021-11-11 12:28:10 +00:00
Martin Atkins
94cbc8fb5d experiments: config_driven_move has concluded
Based on feedback during earlier alpha releases, we've decided to move
forward with the current design for the first phase of config-driven
refactoring.

Therefore here we've marked the experiment as concluded with no changes
to the most recent incarnation of the functionality. The other changes
here are all just updating test fixtures to no longer declare that they
are using experimental features.
2021-11-01 08:46:15 -07:00
James Bardin
cac1f5c264 refactoring: exhaustive NestedWithin checks
When checking dependencies between statements, we need to check all
combinations of To and From addresses.
2021-09-27 12:48:17 -04:00
Martin Atkins
7b99861b1c refactoring: Don't implicitly move for resources with for_each
Our previous rule for implicitly moving from IntKey(0) to NoKey would
apply that move even when the current resource configuration uses
for_each, because we were only considering whether "count" were set.

Previously this was relatively harmless because the resource instance in
question would end up planned for deletion anyway: neither an IntKey nor
a NoKey are valid keys for for_each.

Now that we're going to be announcing these moves explicitly in the UI,
it would be confusing to see Terraform report that IntKey moved to NoKey
in a situation where the config changed from count to for_each, so to
address that we'll only generate the implied statement if neither
repetition argument is set.
2021-09-23 14:37:08 -07:00
Martin Atkins
83f0376673 refactoring: ApplyMoves new return type
When we originally stubbed ApplyMoves we didn't know yet how exactly we'd
be using the result, so we made it a double-indexed map allowing looking
up moves in both directions.

However, in practice we only actually need to look up old addresses by new
addresses, and so this commit first removes the double indexing so that
each move is only represented by one element in the map.

We also need to describe situations where a move was blocked, because in
a future commit we'll generate some warnings in those cases. Therefore
ApplyMoves now returns a MoveResults object which contains both a map of
changes and a map of blocks. The map of blocks isn't used yet as of this
commit, but we'll use it in a later commit to produce warnings within
the "terraform" package.
2021-09-22 09:01:10 -07:00
Martin Atkins
ee9e346039 refactoring: ApplyMoves skips moving when destination address occupied
Per our rule that the content of the state can never make a move statement
invalid, our behavior for two objects trying to occupy the same address
will be to just ignore that and let the object already at the address
take priority.

For the moment this is silent from an end-user perspective and appears
only in our internal logs. However, I'm hoping that our future planned
adjustment to the interface of this function will include some way to
allow reporting these collisions in some end-user-visible way, either as
a separate warning per collision or as a single warning that collects
together all of the collisions into a single message somehow.

This situation can arise both because the previous run state already
contained an object at the target address of a move and because more than
one move ends up trying to target the same location. In the latter case,
which one "wins" is decided by our depth-first traversal order, which is
in turn derived from our chaining and nesting rules and is therefore
arbitrary but deterministic.
2021-09-20 09:06:22 -07:00
Martin Atkins
ef5a1c9cfe refactoring: ImpliedMoveStatements function
This new function complements the existing function FindMoveStatements
by potentially generating additional "implied" move statements that aren't
written explicit in the configuration but that we'll infer by comparing
the configuration and te previous run state.

The goal here is to infer only enough to replicate the effect of the
"count boundary fixup" graph node (terraform.NodeCountBoundary) that we
currently use to deal with this concern of preserving the zero-instance
when switching between "count" and not "count".

This is just dead code for now. A subsequent commit will introduce this
into the "terraform" package while also removing
terraform.NodeCountBoundary, thus achieving the same effect as before but
in a way that'll get reported in the UI as a move, using the same language
that we'd use for an explicit move statement.
2021-09-20 09:06:22 -07:00
Martin Atkins
b4594551f7 refactoring: TestValidateMoves/cyclic_chain can now pass
When originally filling out these test cases we didn't yet have the logic
in place to detect chained moves and so this test couldn't succeed in
spite of being correct.

We now have chain-detection implemented and so consequently we can also
detect cyclic chains. This commit largely just enables the original test
unchanged, although it does include the text of the final error message
for reporting cyclic move chains which wasn't yet finalized when we were
stubbing out this test case originally.
2021-09-15 08:46:12 -07:00
Martin Atkins
4faac6ee43 core: Record move result information in the plan
Here we wire through the "move results" into the graph walk data
structures so that all of the the nodes which produce
plans.ResourceInstanceChange values can capture the "PrevRunAddr" for
each resource instance.

This doesn't actually quite work yet, because the logic in Context.Plan
isn't actually correct and so the updated state from
refactoring.ApplyMoves isn't actually visible as the "previous run state".
For that reason, the context test in this commit is currently skipped,
with the intent of re-enabling it once the updated state is properly
propagating into the plan graph walk and thus we can actually react to
the result of the move while choosing actions for those addresses.
2021-08-30 13:59:14 -07:00
James Bardin
30afb492ab fix ApplyMove test with nested modules working
The addrs package can now correctly handle the combinations of nested
module endpoints, which fixes these 2 tests.
2021-08-20 15:17:06 -04:00
James Bardin
553d6525d2 more move tests 2021-08-19 12:05:53 -04:00
James Bardin
493ec4e6c5 correct the direction and walk order of the graph 2021-08-10 10:12:39 -04:00
James Bardin
08edb02270 MoveStatement.Name()
makes the graph printable for debugging
2021-08-10 10:11:57 -04:00
James Bardin
789317dc05 additional test 2021-08-10 10:11:57 -04:00
James Bardin
6401022bc8 don't take the address of a range variable 2021-08-10 10:11:57 -04:00
James Bardin
09ab952683 fix ApplyMoves tests
Add empty result value, since ApplyMoves does not return nil.
Fix the desired addresses for moves.
2021-08-02 17:23:35 -04:00
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.
2021-07-29 12:29:36 -07:00
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.
2021-07-28 13:54:10 -07:00
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.
2021-07-14 17:37:48 -07:00
Martin Atkins
22eee529e3 addrs: MoveEndpointInModule
We previously built out addrs.UnifyMoveEndpoints with a different
implementation strategy in mind, but that design turns out to not be
viable because it forces us to move to AbsMoveable addresses too soon,
before we've done the analysis required to identify chained and nested
moves.

Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule
which conceptually represents a matching pattern which either matches or
doesn't match a particular AbsMoveable. It does this by just binding the
unified relative address from the MoveEndpoint to the module where it
was declared, and thus allows us to distinguish between the part of the
module path which applies to any instances of the given modules vs. the
user-specified part which must identify particular module instances.
2021-07-14 17:37:48 -07:00