refactoring

package
v1.1.0-alpha20210908 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Sep 8, 2021 License: MPL-2.0 Imports: 12 Imported by: 0

Documentation

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

func ApplyMoves

func ApplyMoves(stmts []MoveStatement, state *states.State) map[addrs.UniqueKey]MoveResult

ApplyMoves modifies in-place the given state object so that any existing objects that are matched by a "from" argument of one of the move statements will be moved to instead appear at the "to" argument of that statement.

The result is a map from the unique key of each absolute address that was either the source or destination of a move to a MoveResult describing what happened at that address.

ApplyMoves does not have any error situations itself, and will instead just ignore any unresolvable move statements. Validation of a set of moves is a separate concern applied to the configuration, because validity of moves is always dependent only on the configuration, not on the state.

ApplyMoves expects exclusive access to the given state while it's running. Don't read or write any part of the state structure until ApplyMoves returns.

func ValidateMoves

func ValidateMoves(stmts []MoveStatement, rootCfg *configs.Config, declaredInsts instances.Set) tfdiags.Diagnostics

ValidateMoves tests whether all of the given move statements comply with both the single-statement validation rules and the "big picture" rules that constrain statements in relation to one another.

The validation rules are primarily in terms of the configuration, but ValidateMoves also takes the expander that resulted from creating a plan so that it can see which instances are defined for each module and resource, to precisely validate move statements involving specific-instance addresses.

Because validation depends on the planning result but move execution must happen _before_ planning, we have the unusual situation where sibling function ApplyMoves must run before ValidateMoves and must therefore tolerate and ignore any invalid statements. The plan walk will then construct in incorrect plan (because it'll be starting from the wrong prior state) but ValidateMoves will block actually showing that invalid plan to the user.

Types

type MoveResult

type MoveResult struct {
	From, To addrs.AbsResourceInstance
}

type MoveStatement

type MoveStatement struct {
	From, To  *addrs.MoveEndpointInModule
	DeclRange tfdiags.SourceRange
}

func FindMoveStatements

func FindMoveStatements(rootCfg *configs.Config) []MoveStatement

FindMoveStatements recurses through the modules of the given configuration and returns a flat set of all "moved" blocks defined within, in a deterministic but undefined order.

func (*MoveStatement) Name

func (s *MoveStatement) Name() string

Name is used internally for displaying the statement graph

func (*MoveStatement) ObjectKind

func (s *MoveStatement) ObjectKind() addrs.MoveEndpointKind

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL