opentofu/command/console.go

212 lines
5.6 KiB
Go
Raw Normal View History

2016-11-14 00:18:18 -06:00
package command
import (
"bufio"
"fmt"
2016-11-14 00:18:18 -06:00
"strings"
"github.com/hashicorp/terraform/addrs"
"github.com/hashicorp/terraform/internal/backend"
"github.com/hashicorp/terraform/internal/helper/wrappedstreams"
"github.com/hashicorp/terraform/internal/repl"
"github.com/hashicorp/terraform/tfdiags"
2016-11-14 00:18:18 -06:00
"github.com/mitchellh/cli"
)
// ConsoleCommand is a Command implementation that applies a Terraform
// configuration and actually builds or changes infrastructure.
type ConsoleCommand struct {
Meta
}
func (c *ConsoleCommand) Run(args []string) int {
args = c.Meta.process(args)
cmdFlags := c.Meta.extendedFlagSet("console")
2016-11-14 00:18:18 -06:00
cmdFlags.StringVar(&c.Meta.statePath, "state", DefaultStateFilename, "path")
cmdFlags.Usage = func() { c.Ui.Error(c.Help()) }
if err := cmdFlags.Parse(args); err != nil {
c.Ui.Error(fmt.Sprintf("Error parsing command line flags: %s\n", err.Error()))
2016-11-14 00:18:18 -06:00
return 1
}
2017-01-18 22:50:45 -06:00
configPath, err := ModulePath(cmdFlags.Args())
2016-11-14 00:18:18 -06:00
if err != nil {
2017-01-18 22:50:45 -06:00
c.Ui.Error(err.Error())
return 1
}
configPath = c.Meta.normalizePath(configPath)
2017-01-18 22:50:45 -06:00
// Check for user-supplied plugin path
if c.pluginPath, err = c.loadPluginPath(); err != nil {
c.Ui.Error(fmt.Sprintf("Error loading plugin path: %s", err))
return 1
}
var diags tfdiags.Diagnostics
backendConfig, backendDiags := c.loadBackendConfig(configPath)
diags = diags.Append(backendDiags)
if diags.HasErrors() {
c.showDiagnostics(diags)
2016-11-14 00:18:18 -06:00
return 1
}
2017-01-18 22:50:45 -06:00
// Load the backend
b, backendDiags := c.Backend(&BackendOpts{
Config: backendConfig,
})
diags = diags.Append(backendDiags)
if backendDiags.HasErrors() {
c.showDiagnostics(diags)
2016-11-14 00:18:18 -06:00
return 1
}
2017-01-18 22:50:45 -06:00
// We require a local backend
local, ok := b.(backend.Local)
if !ok {
c.showDiagnostics(diags) // in case of any warnings in here
2017-01-18 22:50:45 -06:00
c.Ui.Error(ErrUnsupportedLocalOp)
return 1
}
backend: Validate remote backend Terraform version When using the enhanced remote backend, a subset of all Terraform operations are supported. Of these, only plan and apply can be executed on the remote infrastructure (e.g. Terraform Cloud). Other operations run locally and use the remote backend for state storage. This causes problems when the local version of Terraform does not match the configured version from the remote workspace. If the two versions are incompatible, an `import` or `state mv` operation can cause the remote workspace to be unusable until a manual fix is applied. To prevent this from happening accidentally, this commit introduces a check that the local Terraform version and the configured remote workspace Terraform version are compatible. This check is skipped for commands which do not write state, and can also be disabled by the use of a new command-line flag, `-ignore-remote-version`. Terraform version compatibility is defined as: - For all releases before 0.14.0, local must exactly equal remote, as two different versions cannot share state; - 0.14.0 to 1.0.x are compatible, as we will not change the state version number until at least Terraform 1.1.0; - Versions after 1.1.0 must have the same major and minor versions, as we will not change the state version number in a patch release. If the two versions are incompatible, a diagnostic is displayed, advising that the error can be suppressed with `-ignore-remote-version`. When this flag is used, the diagnostic is still displayed, but as a warning instead of an error. Commands which will not write state can assert this fact by calling the helper `meta.ignoreRemoteBackendVersionConflict`, which will disable the checks. Those which can write state should instead call the helper `meta.remoteBackendVersionCheck`, which will return diagnostics for display. In addition to these explicit paths for managing the version check, we have an implicit check in the remote backend's state manager initialization method. Both of the above helpers will disable this check. This fallback is in place to ensure that future code paths which access state cannot accidentally skip the remote version check.
2020-11-13 15:43:56 -06:00
// This is a read-only command
c.ignoreRemoteBackendVersionConflict(b)
2017-01-18 22:50:45 -06:00
// Build the operation
opReq := c.Operation(b)
opReq.ConfigDir = configPath
opReq.ConfigLoader, err = c.initConfigLoader()
opReq.AllowUnsetVariables = true // we'll just evaluate them as unknown
if err != nil {
diags = diags.Append(err)
c.showDiagnostics(diags)
return 1
}
{
var moreDiags tfdiags.Diagnostics
opReq.Variables, moreDiags = c.collectVariableValues()
diags = diags.Append(moreDiags)
if moreDiags.HasErrors() {
c.showDiagnostics(diags)
return 1
}
}
2017-01-18 22:50:45 -06:00
// Get the context
ctx, _, ctxDiags := local.Context(opReq)
diags = diags.Append(ctxDiags)
if ctxDiags.HasErrors() {
c.showDiagnostics(diags)
return 1
}
2016-11-14 00:18:18 -06:00
// Successfully creating the context can result in a lock, so ensure we release it
defer func() {
diags := opReq.StateLocker.Unlock()
if diags.HasErrors() {
c.showDiagnostics(diags)
}
}()
// Set up the UI so we can output directly to stdout
2016-11-14 00:18:18 -06:00
ui := &cli.BasicUi{
Writer: wrappedstreams.Stdout(),
ErrorWriter: wrappedstreams.Stderr(),
2016-11-14 00:18:18 -06:00
}
// Before we can evaluate expressions, we must compute and populate any
// derived values (input variables, local values, output values)
// that are not stored in the persistent state.
scope, scopeDiags := ctx.Eval(addrs.RootModuleInstance)
diags = diags.Append(scopeDiags)
if scope == nil {
// scope is nil if there are errors so bad that we can't even build a scope.
// Otherwise, we'll try to eval anyway.
c.showDiagnostics(diags)
return 1
}
// set the ConsoleMode to true so any available console-only functions included.
scope.ConsoleMode = true
if diags.HasErrors() {
diags = diags.Append(tfdiags.SimpleWarning("Due to the problems above, some expressions may produce unexpected results."))
}
// Before we become interactive we'll show any diagnostics we encountered
// during initialization, and then afterwards the driver will manage any
// further diagnostics itself.
c.showDiagnostics(diags)
2016-11-14 00:18:18 -06:00
// IO Loop
session := &repl.Session{
Scope: scope,
2016-11-14 00:18:18 -06:00
}
// Determine if stdin is a pipe. If so, we evaluate directly.
if c.StdinPiped() {
return c.modePiped(session, ui)
}
return c.modeInteractive(session, ui)
}
func (c *ConsoleCommand) modePiped(session *repl.Session, ui cli.Ui) int {
var lastResult string
scanner := bufio.NewScanner(wrappedstreams.Stdin())
2016-11-14 00:18:18 -06:00
for scanner.Scan() {
result, exit, diags := session.Handle(strings.TrimSpace(scanner.Text()))
if diags.HasErrors() {
// In piped mode we'll exit immediately on error.
c.showDiagnostics(diags)
2016-11-14 00:18:18 -06:00
return 1
}
if exit {
return 0
}
2016-11-14 00:18:18 -06:00
// Store the last result
lastResult = result
}
// Output the final result
ui.Output(lastResult)
return 0
}
func (c *ConsoleCommand) Help() string {
helpText := `
Usage: terraform [global options] console [options]
2016-11-14 00:18:18 -06:00
Starts an interactive console for experimenting with Terraform
interpolations.
This will open an interactive console that you can use to type
interpolations into and inspect their values. This command loads the
current state. This lets you explore and test interpolations before
using them in future configurations.
This command will never modify your state.
Options:
command: Reorganize docs of the local backend's legacy CLI options We have these funny extra options that date back to before Terraform even had remote state, which we've preserved along the way by most recently incorporating them as special-case overrides for the local backend. The documentation we had for these has grown less accurate over time as the details have shifted, and was in many cases missing the requisite caveats that they are only for the local backend and that backend configuration is the modern, preferred way to deal with the use-cases they were intended for. We always have a bit of a tension with this sort of legacy option because we want to keep them documented just enough to be useful to someone who finds an existing script/etc using them and wants to know what they do, but not to take up so much space that they might distract users from finding the modern alternative they should consider instead. As a compromise in that vein here I've created a new section about these options under the local backend documentation, which then gives us the space to go into some detail about the various behaviors and interactions and also to discuss their history and our recommended alternatives. I then simplified all of the other mentions of these in command documentation to just link to or refer to the local backend documentation. My hope then is that folks who need to know what these do can still find the docs, but that information can be kept out of the direct path of new users so they can focus on learning about remote backends instead. This is certainly not the most ideal thing ever, but it seemed like the best compromise between the competing priorities I described above.
2021-03-24 18:17:03 -05:00
-state=path Legacy option for the local backend only. See the local
backend's documentation for more information.
2016-11-14 00:18:18 -06:00
command: Reorganize docs of the local backend's legacy CLI options We have these funny extra options that date back to before Terraform even had remote state, which we've preserved along the way by most recently incorporating them as special-case overrides for the local backend. The documentation we had for these has grown less accurate over time as the details have shifted, and was in many cases missing the requisite caveats that they are only for the local backend and that backend configuration is the modern, preferred way to deal with the use-cases they were intended for. We always have a bit of a tension with this sort of legacy option because we want to keep them documented just enough to be useful to someone who finds an existing script/etc using them and wants to know what they do, but not to take up so much space that they might distract users from finding the modern alternative they should consider instead. As a compromise in that vein here I've created a new section about these options under the local backend documentation, which then gives us the space to go into some detail about the various behaviors and interactions and also to discuss their history and our recommended alternatives. I then simplified all of the other mentions of these in command documentation to just link to or refer to the local backend documentation. My hope then is that folks who need to know what these do can still find the docs, but that information can be kept out of the direct path of new users so they can focus on learning about remote backends instead. This is certainly not the most ideal thing ever, but it seemed like the best compromise between the competing priorities I described above.
2021-03-24 18:17:03 -05:00
-var 'foo=bar' Set a variable in the Terraform configuration. This
flag can be set multiple times.
2016-11-14 00:18:18 -06:00
command: Reorganize docs of the local backend's legacy CLI options We have these funny extra options that date back to before Terraform even had remote state, which we've preserved along the way by most recently incorporating them as special-case overrides for the local backend. The documentation we had for these has grown less accurate over time as the details have shifted, and was in many cases missing the requisite caveats that they are only for the local backend and that backend configuration is the modern, preferred way to deal with the use-cases they were intended for. We always have a bit of a tension with this sort of legacy option because we want to keep them documented just enough to be useful to someone who finds an existing script/etc using them and wants to know what they do, but not to take up so much space that they might distract users from finding the modern alternative they should consider instead. As a compromise in that vein here I've created a new section about these options under the local backend documentation, which then gives us the space to go into some detail about the various behaviors and interactions and also to discuss their history and our recommended alternatives. I then simplified all of the other mentions of these in command documentation to just link to or refer to the local backend documentation. My hope then is that folks who need to know what these do can still find the docs, but that information can be kept out of the direct path of new users so they can focus on learning about remote backends instead. This is certainly not the most ideal thing ever, but it seemed like the best compromise between the competing priorities I described above.
2021-03-24 18:17:03 -05:00
-var-file=foo Set variables in the Terraform configuration from
a file. If "terraform.tfvars" or any ".auto.tfvars"
files are present, they will be automatically loaded.
2016-11-14 00:18:18 -06:00
`
return strings.TrimSpace(helpText)
}
func (c *ConsoleCommand) Synopsis() string {
return "Try Terraform expressions at an interactive command prompt"
2016-11-14 00:18:18 -06:00
}