terraform

Commit Graph

Author	SHA1	Message	Date
kmoe	b4d1146f58	plannable import: improve gen config human plan output (#33194 ) * renderer: remove hard-coded config gen path * mention config gen file in plan next steps	3 years ago
CJ Horton	5d7864316e	Merge pull request #33160 from hashicorp/radditude/apply-counts Populate import counts during applies and clean up output	3 years ago
Liam Cervante	4d837df546	Plannable import: Add generated config to JSON and human-readable plan output (#33154 ) * command: keep our promises * remove some nil config checks Remove some of the safety checks that ensure plan nodes have config attached at the appropriate time. * add GeneratedConfig to plan changes objects Add a new GeneratedConfig field alongside Importing in plan changes. * add config generation package The genconfig package implements HCL config generation from provider state values. Thanks to @mildwonkey whose implementation of terraform add is the basis for this package. * generate config during plan If a resource is being imported and does not already have config, attempt to generate that config during planning. The config is generated from the state as an HCL string, and then parsed back into an hcl.Body to attach to the plan graph node. The generated config string is attached to the change emitted by the plan. * complete config generation prototype, and add tests * Plannable import: Add generated config to json and human-readable plan output --------- Co-authored-by: Katy Moe <katy@katy.moe>	3 years ago
CJ Horton	bc084858b1	add import hooks for plan and apply Separate hooks used for the legacy import command for those used by the new import mechanism; also add apply output for imports.	3 years ago
Liam Cervante	2793af042c	Revert "Plannable import: Make the streamed logs more consistent during a plan operation (#33155 )" This reverts commit `3c20f7b340`.	3 years ago
Liam Cervante	3c20f7b340	Plannable import: Make the streamed logs more consistent during a plan operation (#33155 )	3 years ago
hashicorp-copywrite[bot]	bb36298b21	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Liam Cervante	81eb73731d	[Plannable Import] Implement streamed logs for plan (#33106 ) * [plannable import] embed the resource id within the changes * [Plannable Import] Implement streamed logs for -json plan * use latest structs * remove implementation plans from TODO	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Liam Cervante	978263efe9	Checks: Introduce check blocks into the terraform node and transform graph (#32735 ) * Add support for scoped resources * refactor existing checks addrs and add check block addr * Add configuration for check blocks * introduce check blocks into the terraform node and transform graph * address comments * address comments * don't execute checks during destroy operations * don't even include check nodes for destroy operations	3 years ago
Liam Cervante	d818d7850d	Structured Renderer: use the new renderer when rendering the state in addition to the plan (#32629 ) * Use the new renderer when rendering the state * remove confusing and unneeded comment	3 years ago
zetHannes	c70244426a	Fix for no json output of state locking actions for --json flag (#32451 ) * Add viewType to Meta object and use it at the call sites * Assign viewType passed from flags to state-locking cli commands * Remove temp files * Set correct mode for statelocker depending on json flag passed to commands * Add StateLocker interface conformation check for StateLockerJSON * Remove empty line at end of comment * Pass correct ViewType to StateLocker from Backend call chain * Pass viewType to backend migration and initialization functions * Remove json processing info in process comment * Restore documentation style of backendMigrateOpts	3 years ago
Liam Cervante	6dc49150b7	Structured Plan Renderer: Read the data source schemas from the right place (#32532 ) * read the data source schemas from the right place * address comments and add test	3 years ago
Liam Cervante	8d61c5bfc4	Use the new structured renderer in place of the old diffs package (#32520 ) * Use the new structured renderer in place of the old diffs package * remove old plan tests * refresh only plans should show moved resources in the refresh section	3 years ago
Martin Atkins	4660dacd59	command: Prototype of handling errored plans This is a prototype of how the CLI layer might make use of Terraform Core's ability to produce a partial plan if it encounters an error during planning, with two new situations: - When using local CLI workflow, Terraform will show the partial plan before showing any errors. - "terraform plan" has a new option -always-out=..., which is similar to the existing -out=... but additionally instructs Terraform to produce a plan file even if the plan is incomplete due to errors. This means that the plan can still be inspected by external UI implementations. This is just a prototype to explore how these parts might fit together. It's not a complete implementation and so should not be shipped. In particular, it doesn't include any mention of a plan being incomplete in the "terraform show -json" output or in the "terraform plan -json" output, both of which would be required for a complete solution.	3 years ago
UKEME BASSEY	7b34e3e743	redact sensitive output values in run logs	4 years ago
kmoe	dec48a8510	plans: indicate when resource deleted due to move (#31695 ) Add a new ChangeReason, ReasonDeleteBecauseNoMoveTarget, to provide better information in cases where a planned deletion is due to moving a resource to a target not in configuration. Consider a case in which a resource instance exists in state at address A, and the user adds a moved block to move A to address B. Whether by the user's intention or not, address B does not exist in configuration. Terraform combines the move from A to B, and the lack of configuration for B, into a single delete action for the (previously nonexistent) entity B. Prior to this commit, the Terraform plan will report that resource B will be destroyed because it does not exist in configuration, without explicitly connecting this to the move. This commit provides the user an additional clue as to what has happened, in a case in which Terraform has elided a user's action and inaction into one potentially destructive change.	4 years ago
kmoe	621af43c04	fix missing output for applyable refresh plans (#31469 )	4 years ago
Martin Atkins	72dd14ca5c	core: Do everything except the actual action for plans.NoOp Previously we tried to early-exit before doing anything at all for any no-op changes, but that means we also skip some ancillary steps like evaluating any preconditions/postconditions. Now we'll skip only the main action itself for plans.NoOp, and still run through all of the other side-steps. Since one of those other steps is emitting events through the hooks interface, this means that now no-op actions are visible to hooks, whereas before we always filtered them out before calling. I therefore added some additional logic to the hooks to filter them out at the UI layer instead; the decision for whether or not to report that we visited a particular object and found no action required seems defensible as a UI-level concern anyway.	4 years ago
Martin Atkins	90ea7b0bc5	tfdiags: Treat unknown-related or sensitive-related messages differently By observing the sorts of questions people ask in the community, and the ways they ask them, we've inferred that various different people have been confused by Terraform reporting that a value won't be known until apply or that a value is sensitive as part of an error message when that message doesn't actually relate to the known-ness and sensitivity of any value. Quite reasonably, someone who sees Terraform discussing an unfamiliar concept like unknown values can assume that it must be somehow relevant to the problem being discussed, and so in that sense Terraform's current error messages are giving "too much information": information that isn't actually helpful in understanding the problem being described, and in the worst case is a distraction from understanding the problem being described. With that in mind then, here we introduce an explicit annotation on diagnostic objects that are directly talking about unknown values or sensitive values, and then the diagnostic renderer will react to that to avoid using the terminology "known only after apply" or "sensitive" in the generated diagnostic annotations unless we're rendering a message that is explicitly related to one of those topics. This ends up being a bit of a cross-cutting concern because the code that generates these diagnostics and the code that renders them are in separate packages and are not directly aware of each other. With that in mind, the logic for actually deciding for a particular diagnostic whether it's flagged in one of these special ways lives inside the tfdiags package as an intermediation point, which both the diagnostic generator (in the core package) and the diagnostic renderer can both depend on.	4 years ago
Martin Atkins	31aee9650e	command/format: Include function call information in diagnostics When an error occurs in a function call, the error message text often includes references to particular parameters in the function signature. This commit improves that reporting by also including a summary of the full function signature as part of the diagnostic context in that case, so a reader can see which parameter is which given that function arguments are always assigned positionally and so the parameter names do not appear in the caller's source code.	4 years ago
Martin Atkins	4cffff24b1	core: Report reason for deferring data read until apply We have two different reasons why a data resource might be read only during apply, rather than during planning as usual: the configuration contains unknown values, or the data resource as a whole depends on a managed resource which itself has a change pending. However, we didn't previously distinguish these two in a way that allowed the UI to describe the difference, and so we confusingly reported both as "config refers to values not yet known", which in turn led to a number of reasonable questions about why Terraform was claiming that but then immediately below showing the configuration entirely known. Now we'll use our existing "ActionReason" mechanism to tell the UI layer which of the two reasons applies to a particular data resource instance. The "dependency pending" situation tends to happen in conjunction with "config unknown", so we'll prefer to refer that the configuration is unknown if both are true.	4 years ago
James Bardin	7da52d94f2	Merge pull request #30900 from hashicorp/jbardin/replace-triggered-by Configurable instance replacement via lifecycle `replace_triggered_by`	4 years ago
James Bardin	c52e3ed37b	test fixture race	4 years ago
James Bardin	3a0a019521	round-trip replace triggers	4 years ago
James Bardin	09dde8d5ed	improve the contributing attributes filter The initial rough implementation contained a bug where it would incorrectly return a NilVal in some cases. Improve the heuristics here to insert null values more precisely when parent objects change to or from null. We also check for dynamic types changing, in which case the entire object must be taken when we can't match the individual attribute values.	4 years ago
James Bardin	f0cd8be66f	add whole resource references	4 years ago
James Bardin	e2b74247f2	track contributing instances Track individual instance drift rather than whole resources which contributed to the plan. This will allow the output to be more precise, and we can still use NoKey instances as a proxy for containing resources when needed.	4 years ago
James Bardin	25f4c0d3dd	filter attribute refresh changes from plan UI Filter the refresh changes from the normal plan UI at the attribute level. We do this by constructing fake plans.Change records for diff generation, reverting all attribute changes that do not match any of the plan's ContributingResourceReferences.	4 years ago
James Bardin	0e7cec83db	decode change before creating diff This is functionally equivalent, but will allow us to filter the change values directly for reduced drift output.	4 years ago
James Bardin	c02e8bc5b3	change plan to store individual relevant attrs Storing individual contributing attributes will allow finer tuning of the plan rendering. add contributing to outputs	4 years ago
James Bardin	f1e8aed48d	output drift footer in the right place	4 years ago
James Bardin	c5c7045a89	filter out non-relevant drift changes Only show drift changes which may have affected the plan output.	4 years ago
James Bardin	a151aaef05	only show drift when there are changes	4 years ago
Krista LaFentres	fea8f6cfa2	cli: Migrate show command to use command arguments and views	4 years ago
Martin Atkins	5b266dd5ca	command: Remove the experimental "terraform add" command We introduced this experiment to gather feedback, and the feedback we saw led to us deciding to do another round of design work before we move forward with something to meet this use-case. In addition to being experimental, this has only been included in alpha releases so far, and so on both counts it is not protected by the Terraform v1.0 Compatibility Promises.	5 years ago
Alisdair McDiarmid	b9f3dab035	json-output: Release format version 1.0	5 years ago
Alisdair McDiarmid	b699391d04	json-output: Add change reasons to explain deletes The extra feedback information for why resource instance deletion is planned is now included in the streaming JSON UI output. We also add an explicit case for no-op actions to switch statements in this package to ensure exhaustiveness, for future linting.	5 years ago
Alisdair McDiarmid	b59b057591	json-output: Config-driven move support in JSON UI Add previous address information to the `planned_change` and `resource_drift` messages for the streaming JSON UI output of plan and apply operations. Here we also add a "move" action value to the `change` object of these messages, to represent a move-only operation. As part of this work we also simplify this code to use the plan's DriftedResources values instead of recomputing the drift from state.	5 years ago
Alisdair McDiarmid	638784b195	cli: Omit move-only drift, except for refresh-only The set of drifted resources now includes move-only changes, where the object value is identical but a move has been executed. In normal operation, we previousl displayed these moves twice: once as part of drift output, and once as part of planned changes. As of this commit we omit move-only changes from drift display, except for refresh-only plans. This fixes the redundant output.	5 years ago
Alisdair McDiarmid	d425c26d77	Merge pull request #29589 from hashicorp/alisdair/planfile-drifted-resources core: Compute resource drift during plan phase, store in plan file	5 years ago
Alisdair McDiarmid	1f57b7a8bd	Merge pull request #29235 from magodo/terraform_add_output_append `terraform add`: `-out` option append to existing config & optionally check resource existance	5 years ago
Alisdair McDiarmid	f0cf4235f9	cli: Refactor resource drift rendering	5 years ago
Alisdair McDiarmid	cd29c3e5fd	Revert "json-output: Release format version 1.0"	5 years ago
Laura Pacilio	a819d7db3a	Merge pull request #29502 from hashicorp/alisdair/json-format-version json-output: Release format version 1.0	5 years ago
Alisdair McDiarmid	29999c1d6f	command: Render "moved" annotations in plan UI For resources which are planned to move, render the previous run address as additional information in the plan UI. For the case of a move-only resource (which otherwise is unchanged), we also render that as a planned change, but without any corresponding action symbol. If all changes in the plan are moves without changes, the plan is no longer considered "empty". In this case, we skip rendering the action symbols in the UI.	5 years ago
Alisdair McDiarmid	b60f201eed	json-output: Release format version 1.0	5 years ago
James Bardin	863963e7a6	de-linting	5 years ago
Martin Atkins	43d753e727	command: "terraform add" is experimental We're aware of several quirks of this command's current design, which result from some existing architectural limitations that we can't address immediately. However, we do still want to make this command available in its current capacity as an incremental improvement, so as a compromise we'll document it as experimental. Our intent here is to exclude it from the Terraform 1.0 Compatibility Promises so that we can have the space to continue to improve the design as other parts of the overall Terraform system gain new capabilities. We don't currently have any concrete plan for this command to be stabilized and subject to compatibility promises. That decision will follow from ongoing discussions with other teams whose systems may need to change in order to support the final design of "terraform add".	5 years ago
Alisdair McDiarmid	3b33dc1105	json-output: Add output changes to plan logs Extend the outputs JSON log message to support an `action` field (and make the `type` and `value` fields optional). This allows us to emit a useful output change summary as part of the plan, bringing the JSON log output into parity with the text output. While we do have access to the before/after values in the output changes, attempting to wedge those into a structured log message is not appropriate. That level of detail can be extracted from the JSON plan output from `terraform show -json`.	5 years ago

1 2

68 Commits (be2ad69eda9c66ca2c3ee793720d79faee997334)