2447 Commits (eecbfbf2cccedfb581469ee63599c4b4abc5c60f)

Author	SHA1	Message	Date
Jared Baker	54866790ca	backend/s3: remove use_legacy_workflow argument ... The `use_legacy_workflow` argument has been removed to encourage consistency with the AWS SDKs. The backend will now search for credentials in the same order as the default provider chain in the AWS SDKs and AWS CLI.	2 years ago
Daniel Schmidt	8564e934aa	Merge pull request #34699 from hashicorp/terraform-test-use-vars-within-blocks ... test: allow using global variables in suite-level variable definitions	2 years ago
Daniel Schmidt	4f23efc14e	remove unused config	2 years ago
Daniel Schmidt	5a72e696ce	check for presence and not for warnings	2 years ago
Daniel Schmidt	0529299cc3	run terraform fmt on test	2 years ago
Daniel Schmidt	a4651fac4c	append diags unconditionally	2 years ago
Daniel Schmidt	57f6ce81b5	rename suite to file and make var internal	2 years ago
Daniel Schmidt	6a4ef8e2b3	fix comment ... Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>	2 years ago
Daniel Schmidt	631293060b	only extract global and suite level variables once	2 years ago
Alisdair McDiarmid	f9998ff2a5	configs: Remove unused *Parser.LoadValuesFile	2 years ago
Daniel Schmidt	5bed43c16d	remove whitespace	2 years ago
Daniel Schmidt	e57368045c	fix implementation of variable checking	2 years ago
Daniel Schmidt	df3ee21d82	extract global and suite-level variables before configuring providers	2 years ago
Daniel Schmidt	697e0d1d9e	refactor variable extraction	2 years ago
Liam Cervante	b3abff5750	stacks: check providers blocks in components during validatation (#34707)	2 years ago
Liam Cervante	bced645a4d	stacks: call terraform.Validate on stack component configs (#34705)	2 years ago
Liam Cervante	c46515c5da	stacks: add support for external providers to validate context (#34701)	2 years ago
Liam Cervante	2472f7c773	stacks: fix flaky tests (#34708)	2 years ago
Daniel Schmidt	7ae7a203d8	test: allow using global variables in suite-level variable definitions ... Closes #34534	2 years ago
Liam Cervante	82361afd73	plan rendering: fix truncation of very large numbers (#34702)	2 years ago
Alisdair McDiarmid	48148eda5f	Merge pull request #34687 from hashicorp/alisdair/stackeval-hook-replace-action-counts ... stackeval: Add support for replace actions to hook	2 years ago
Daniel Schmidt	adf008d489	adjust tests to new implementation	2 years ago
Daniel Schmidt	19f9bdac14	handle multi-line string diffs correctly	2 years ago
Daniel Schmidt	a64df71152	fix comment	2 years ago
Daniel Schmidt	1531fee472	clarify comment	2 years ago
Daniel Schmidt	2a625b75a4	handle reordering explicitly	2 years ago
Daniel Schmidt	31bd2b5be0	plan: compare individual elements if list is same length ... Closes #33779	2 years ago
Liam Cervante	64b311d53a	stacks: apply sensitive marks to outputs from components (#34684) ... * stacks: apply sensitive marks to outputs from components * gen headers * ensure consistent test ordering	2 years ago
Liam Cervante	f0b61090a2	Move the testing MockProvider into a dedicated shared package (#34681) ... * move the testing MockProvider into a dedicated shared package * address comments * fix new changes	2 years ago
Alisdair McDiarmid	06723d3d4b	stackeval: Add support for replace actions to hook ... The terraform.Hook implementation in stackeval is used to track the operations performed during stack runtime operations, for later reporting to the caller. This hook did not correctly support the replace actions (create-then-destroy, destroy-then-create), resulting in a loss of data between plan and apply. This exhibited as a plan with a replace reporting 1 add and 1 remove operation, which when applied would report only 1 add operation. Previously, we stored the action performed for each apply operation on a given resource instance in the PreApply hook, then allowed access to it via the ResourceInstanceObjectAppliedAction method. Here we extend the PostApply hook to look for a previous action performed on this instance, and use that to reconstruct the planned replace action. This method is called in the stackruntime package, where replace operations are counted for both add and remove. No changes are needed at the call site to fix the bug.	2 years ago
Martin Atkins	fde6277565	stackruntime: Pass ExperimentsAllowed into stackeval for apply ... This was originally part of 7dad938fdb but unfortunately seems to have got lost during some rebasing, or some other similar sort of annoying reason. This now allows the "experiments allowed" flag to propagate into the stackeval package when we're running the apply phase, for consistency with all of the other phases. Without this, it's possible to plan a configuration that's participating in experiments, but then it fails in a strange way during the apply step due to Terraform suddenly thinking it's a stable release where experiments are disabled.	2 years ago
James Bardin	084bce65dc	Merge pull request #34683 from hashicorp/jbardin/detect-unknown-provider-functions ... Better diagnostics for unknown provider functions	2 years ago
James Bardin	336145c384	update diagnostic message	2 years ago
James Bardin	bac2f892c6	more helpful provider function diagnostics ... Use the new FunctionCallUnknownDiagExtra feature from hcl to help guide users through problems with provider function calls. Now that we can detect diagnostics from unknown function calls, we can correlate the namespace and names with certain problems specific to Terraform.	2 years ago
Liam Cervante	07f6621091	stacks: include resources in state when calculating required providers (#34645) ... * stacks: include resources in state when calculating required providers * also support apply time * add copywrite headers	2 years ago
CJ Horton	7a37c393a0	Merge pull request #34678 from hashicorp/radditude/standard-panics ... standardize panic output	2 years ago
CJ Horton	6e1e00ae3f	standardize panic output ... Programs that monitor Terraform's output to report panics might make the reasonable assumption that the string "panic:" is always included and is therefore safe to monitor for. Our custom panic output unfortunately breaks these assumptions at the moment. Instead of asking consumers to add their own handling to deal with this problem, let's add that greppable string to our custom panic output.	2 years ago
Radek Simko	0c509183d1	ci: Add test for license headers (#34624) ... * ci: Add test for copyright headers * replace GHA workflow with make target (copyright) This makes it reusable for outside of CI, such that anyone cloning the repo locally can still easily verify compliance before raising a PR. * remove go:generate for copywrite This should no longer be needed as we leverage copywrite via a shell script now. * introduce make copyrightfix	2 years ago
Martin Atkins	a77d351ea2	plugin+plugin6: Don't panic if ProviderMeta not populated ... "ProviderMeta" is a niche feature that's used by only two providers, but this code was written under the assumption that the caller would always provide it for any provider that has a schema for it, and unfortunately the Terraform SDK seems to always provide a meta schema even for providers that don't use it, and thus it's empty. The current phase of the "unknown_instances" language experiment is not fully wired in to the main logic as a way to reduce the risk of it impacting behavior for those not participating in the experiment, but that means that right now it doesn't actually have a resolved ProviderMeta value to present, and so was just omitting it on the assumption that it is always optional to provide anyway. As a pragmatic stopgap to resolve that conflict, this makes the gRPC provider dispatching logic tolerate an absent ProviderMeta value and synthesize a null value to use in that case. This makes that logic slightly more robust and also means we can defer doing all of the work to weave ProviderMeta into this experimental codepath. The new TODO comment in that codepath is intended to remind us to consider this again should we decide to stablize the experiment later; when we do that, we'll hopefully do it by refactoring to share more code between the two codepaths, at which point ProviderMeta will be easier to support.	2 years ago
Liam Cervante	58289db4a9	terraform test: use platform independent path functions (#34666)	2 years ago
Martin Atkins	e6665c4f43	stackeval: Basic support for deferred-change propagation ... This is the bare minimum functionality to ensure that we defer all actions in any component that depends on a component that already had deferred actions. We will also eventually need to propagate out a signal to the caller for whether the stack plan as a whole is complete or incomplete, but we'll save that for later commits, since the stack orchestration in Terraform Cloud will do the right thing regardless, aside from the cosmetic concern that it won't yet know to show a message to the user saying that there are deferred changes.	2 years ago
Martin Atkins	2e6cf0a518	terraform: Callers can force all actions to be deferred ... When the modules runtime is being used inside the stacks runtime, it's possible that a component could refer to another component that has deferred changes in its plan. In that case, we do still want to plan the downstream component (to give earlier feedback if there are obvious problems with it) but we need to force all planned actions to be treated as deferred so that we preserve the correct dependency ordering across all objects described in a stack. This commit only deals with the modules runtime handling that case. We'll make the stacks runtime use it in a subsequent commit.	2 years ago
Martin Atkins	823aa8e4f3	terraform: Handle partial-expanded resources during planning ... When at least one module in the configuration is opted in to the unknown_instances language experiment, we'll now divert into an experimental adaptation of nodeExpandPlannableResource.DynamicExpand which knows how to deal with partial-expanded modules and resources. Whenever a partial-expanded resource prefix is detected, we'll make a special graph node for it which goes through some of the motions of planning but does so only really for the side-effect of checking the configuration for dynamic errors. We do also save the result as a placeholder value for the object for completeness, although it's not really used for much yet because the partial-expansion tracker saves this primarily for reporting information about the deferred changes as extra context in the plan, and we're not implementing that yet. This isn't yet quite right because we're not preserving enough information from plan phase to apply phase to correctly handle references to the resources that had deferred actions. However, since this is currently just an experiment anyway, this is a useful interim milestone that shows at least that things are functional enough to converge on the correct result in the end. We'll correct the evaluation misses (as documented in the TestContext2Apply_deferredActionsResourceForEach test) in subsequent commits, which will require tracking a little more information in the saved plan so that we can re-populate all of the deferral metadata when we start the apply phase.	2 years ago
Martin Atkins	a0b0996ad1	terraform: Evaluator returns DynamicVal for partial-expanded resource ... For now this is just an up-top weird exception to minimize the impact on the code that's runs when not participating in the unknown_instances experiment. In future it would be nice to rework this GetResource method to rely on the ResourceInstanceKeys result even in the known case, since that will simplify this function and remove a some duplicate code, but our priority for now is minimizing the possibility that the code for this experiment can impact users who are not participating in the experiment.	2 years ago
Martin Atkins	64f7b6992f	terraform: BuiltinEvalContext function eval in partial-expanded module ... An earlier commit changed the EvalContext model to support evaluation in both fully-expanded and partial-expanded modules, but the provider-contributed functions feature landed semi-concurrently with it and so inadvertently introduced a codepath that only worked in the fully-expanded case. This will now handle both situations, since all we really need is the addrs.Module, which we can obtain in both modes.	2 years ago
Martin Atkins	d574082caf	terraform: nodeExpandModule must check experiments on moduleCtx ... Previously we were incorrectly checking for the experiment being enabled on the global EvalContext, but that doesn't make sense because experiments are explicitly module-specific. Now we'll ask the question separately for each module so we can use the module-scoped EvalContext.	2 years ago
Martin Atkins	3e2b6ffec8	core: Resource nodes aware when unknown_instances experiment is on ... Usually language experiments have single-module scope, but this particular one can potentially force modules other than the one that opt in to do some behavior differently for correct results. To minimize the risk of the new experiment code impacting those who are not participating in the experiment, we'll want to branch into a new DynamicExpand codepath only when at least one module is participating in the experiment, but graph nodes alone have a more tightly-scoped view that prevents them from answering that question directly, and so we'll temporarily ask the ConfigTransformer to help in detecting that up top and propagating the result into all of the resource nodes. This commit doesn't yet make use of the new temporary field; that'll follow in a subsequent commit that introduces the new partial-expansion-aware alternative DynamicExpand codepath.	2 years ago
Martin Atkins	47fd5e3e35	terraform: Expose a shared deferring.Deferred object ... As with the various other context-tracking containers we use during graph walks, we'll need a deferring.Deferred object shared across all graph nodes' EvalContexts and with the expression evaluator so that we can report deferrals and then make decisions based on deferrals previously registered upstream. As of this commit we're not yet doing anything with this new object, but in future commits we'll use it to report what we've deferred and to "artifically" defer anything that has a side-effect and depends on something else that's already been deferred.	2 years ago
Martin Atkins	db07b905e9	deferring: A new package for tracking deferred actions ... When we defer planning actions that have direct side-effects -- that is, resource instance actions -- we need to remember that we did so because we then need to force deferring planning for any other resources downstream to preserve the required order of operations. That means we need to keep track of what we've already deferred so we can check whether a newly-visited resource instance must also be deferred. We also need to track deferrals for the purpose of reporting them as part of the plan presented to the end-user. This change _starts_ to implement that, but for now the public API is limited only to generating a boolean signal for whether there are any deferrals at all, because that's the minimum possible reporting that allows for correct behavior (so the caller can treat the resulting plan slight differently in the workflow). In future we'll also want to be able to return placeholder values for not-yet-expanded resource instances, but that's not fully built out here yet since for an initial implementation we can cheat and use cty.DynamicVal as a universal "we know nothing at all" placeholder. This API is likely to grow and change in forthcoming commits as we continue wiring these new behaviors into the Terraform modules runtime.	2 years ago
Martin Atkins	53f00667d5	instances: Some additional commentary ... The internal API here was a little unclear, so this is just some retroactive additional documentation resulting from me having "relearned" how this API works after some time away from it, in the hope that future maintainers will not need to repeat that exercise.	2 years ago
Martin Atkins	8e02f5dd21	addrs: PartialExpandedResource module address accessors ... This is kinda awkward because this address type represents both resources whose own instances are not expanded yet and resources belonging to whole modules whose instance keys haven't been expanded yet, and those two cases have different address types. However, in return for this awkward API only for the rare case where we need to isolate the module instance address, the rest of the system gets to not worry very much about this distinction: it can share most code between the two cases, since they both need similar evaluation treatment anyway.	2 years ago
Martin Atkins	67d8a5137b	rpcapi+stacks: Stacks runtime can see whether experiments are allowed ... We allow experiments only in alpha builds, and so we propagate the flag for whether that's allowed in from "package main". We previously had that plumbed in only as far as the rpcapi startup. This plumbs the flag all the way into package stackeval so that we can in turn propagate it to Terraform's module config loader, which is ultimately the one responsible for ensuring that language experiments can be enabled only when the flag is set. Therefore it will now be possible to opt in to language experiments in modules that are used in stack components.	2 years ago
Martin Atkins	73df33fe6e	instances: Fix data race in Expander.ExpandAbsModuleCall ... This method must hold a read lock while it does its work, or else it will race with calls to register the expansion mode for other module calls.	2 years ago
Martin Atkins	e6ce1edf22	logging: Send captured panics to real stderr ... Our goal with this panic-interception was to largely mimic how the Go runtime would normally report panics except for two intentional exceptions: an extra prompt explaining to the user that Terraform crashed, and exiting with status code 11 instead of 2. Unfortunately we accidentally deviated in a different way: we're reporting to whatever os.Stderr happens to refer to, instead of to the real process stderr. It seems like that shouldn't really matter, but unfortunately go-plugin intentionally changes os.Stderr to refer to a totally separate stream that it manages, causing the captured panic messages to be routed over a grpc-based channel to the plugin client. This deviation makes the panic messages not visible to usual strategies for trying to heuristically detect that a Go program has panicked. Without a special interception like Terraform is doing here, the Go runtime writes directly to the stderr file descriptor without going through the os.Stderr abstraction, and so to achieve consistent behavior we need to do a little hoop-jumping to approximate that result. In particular, this makes the behavior now consistent with what happens when a provider plugin running as a child of Terraform Core panics, and so a system which tries to sniff stderr for content that seems like a panic message will be able to handle both situations equally and avoid making a special case for Terraform Core/CLI's own panics.	2 years ago
Ansgar Mertens	cd1306430b	fix(docs): Include product in relative link (#34510) ... CDKTF uses these definitions to generate docs which end up on developer.hashicorp.com There are content checks that fail for this link as the product (terraform) is required to be explicitly stated now	2 years ago
Liam Cervante	3475d22741	Fix nil pointer exception when planning stacks with undeclared variables (#34638) ... * fix nil pointer exception when planning with undeclared variables * another function does the same	2 years ago
Alisdair McDiarmid	55675b990a	stackeval: Unmark provider config for plugin RPC ... When validating or applying a provider configuration, we must unmark the value before attempting to use plugin RPC, as we cannot serialize marks.	2 years ago
Martin Atkins	884e1fb2a4	terraform: Plans can be "complete" and "applyable" ... These ideas are both already implied by some logic elsewhere in the system, but until now we didn't have the decision logic centralized in a single place that could therefore evolve over time without necessarily always updating every caller together. We'll now have the modules runtime produce its own boolean ruling about each characteristic, which callers can rely on for the mechanical decision-making of whether to offer the user an "approve" prompt, and whether to remind the user after apply that it was an incomplete plan that will probably therefore need at least one more plan/apply round to converge. The "Applyable" flag directly replaces the previous method Plan.CanApply, with equivalent logic. Making this a field instead of a method means that we can freeze it as part of a saved plan, rather than recalculating it when we reload the plan, and we can export the field value in our export formats like JSON while ensuring it'll always be consistent with what Terraform is using internally. Callers can (and should) still use other context in the plan to return more tailored messages for specific situations they already know about that might be useful to users, but with these flags as a baseline callers can now just fall back to a generic presentation when encountering a situation they don't yet understand, rather than making the wrong decision and causing something strange to happen. That is: a lack of awareness of a new rule will now cause just a generic message in the UI, rather than incorrect behavior. This commit mostly just deals with populating the flags, and then all of the direct consequences of that on our various tests. Further changes to actually make use of these flags elsewhere in the system will follow in later commits, both in this repository and in other repositories.	2 years ago
Daniel Schmidt	9fbe6c6a13	Merge pull request #34632 from hashicorp/use-plugin-cache-for-provider-lock ... improve provider lock speed by using cache	2 years ago
Daniel Schmidt	a08b108346	Merge pull request #34630 from hashicorp/wrap-json-in-generated-config-in-tf-function ... In import-generated code represent JSON values in HCL instead of as strings	2 years ago
Daniel Schmidt	91ea23aee5	remove outdated comment	2 years ago
Daniel Schmidt	14feb738a7	update comment	2 years ago
Daniel Schmidt	472a07ad6e	fix typo ... Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>	2 years ago
Daniel Schmidt	be262b52d7	make using the plugin cache opt-in	2 years ago
Daniel Schmidt	f720a060ff	use plugin cache for provider lock across for all platforms ... The cache architecture already supports multi-platform, the only downside is that this might grow the cache. This seems expected.	2 years ago
Daniel Schmidt	2c98e6a347	improve provider lock speed by using cache ... Closes #33837	2 years ago
Daniel Schmidt	5b29b92abe	Merge pull request #34625 from hashicorp/throw-better-error-if-import-id-is-empty-string ... fix panic when import id is empty string	2 years ago
Daniel Schmidt	ba043a04d5	in import-generated code represent JSON values in HCL instead of as strings ... This makes the value easier to read and is mostly an aesthetic change. Closes #34444	2 years ago
Daniel Schmidt	2b7c7b2745	fix panic when import id is empty string ... We can only detect this during evaluation since the import id is an hcl expression. Fixes #33505	2 years ago
Martin Atkins	34ccf284fa	terraform: Further generalization of the EvalContext scope handling ... This is a continuation of some restructuring started in earlier commits: 641837df7b 42f012bee4 079021df1b In those earlier commits my goal was to minimize breaking changes to the EvalContext API to churn existing code as little as possible. However, the way I achieved that was to handle fully-expanded modules and partial-expanded modules as two completely separate codepaths, which means that all other code must statically decide which of the two cases it's dealing with even though there's not really any reason the EvalContext implementation couldn't support that being decided dynamically. For the "deferred actions" work, in a future commit we'll need to introduce a new graph node type representing partial-expanded resources which must decide dynamically whether it's in a fully-expanded module scope or a partial-expanded module scope, because the treatment is quite different for a fully-expanded module containing a resource with unknown expansion vs. a resource that's inside a module that hasn't been expanded itself. This is therefore the logical conclusion of the previous work, making "eval context scope" the primary way that we talk about where an eval context is doing its work, with a helper function for the common case where that's a fully-expanded ModuleInstance. In particular, this includes a third variation of the family of interfaces that have method Path indicating the scope that the node should be evaluated in, which is allowed to return any non-nil evalContextScope chosen dynamically at runtime. The existing interfaces that statically return addrs.ModuleInstance and addrs.PartialExpandedModule remain as statically-typed alternatives for the common case, since the need to decide dynamically is (for now) limited only to nodes representing addrs.PartialExpandedResource addresses. This has unfortunately now churned a little more code than I originally wanted to, but the helper functions and the retaining of the statically-typed node-scope-discovery interfaces has kept it as small as possible. (This also continues our effort to gradually make the implementation details of package terraform be unexported, at the expense of a little inconsistency in the short term where these new fields/types are mixed in with exported fields/types. Hopefully we'll continue on this quest over time and eventually reach things being consistently unexported.)	2 years ago
Daniel Schmidt	ccf8bb20d8	Merge pull request #34619 from DanielMSchmidt/add-is-sensitive-function ... add `issensitive` function	2 years ago
Daniel Schmidt	cf4d99a926	if file provisioners source is null throw error instead of panic ... Fixes #34454	2 years ago
Daniel Schmidt	3a77065e69	add `issensitive` function ... This function can be used to check if a value is marked as sensitive or not within terraform. Closes #34572	2 years ago
Radek Simko	30aa3cb743	rpcapi: Add missing license headers & code-generation headers (#34617)	2 years ago
Liam Cervante	8522c40114	terraform test: prevent crash when mocking dynamic types (#34607)	2 years ago
Martin Atkins	89a53e9105	command/test: Fix invalid XML processing instruction ... Annoyingly, I seem to have flubbed this slightly while I was adapting to use enc.EncodeToken instead of (as originally written) just writing the literal processing instruction bytes onto the front of the buffer directly. This made the output invalid for any XML processor that interprets the special "xml" processing instruction. It'll now be valid again.	2 years ago
James Bardin	a8701f6ddd	provider functions return an error ... The call site for language functions doesn't currently have a way to handle complex diagnostics, so rather than appear to support them in the protocol we remove the concepts of diagnostics for now. We do however retain the argument index fields, which we can wrap in a function.ArgError and get a little more precise hcl diagnostic from expression.	2 years ago
Liam Cervante	9c39e51466	Add 'explicit configuration required' message when provider schema validation fails (#34595)	2 years ago
Martin Atkins	ac5f6489c4	core: Placeholder values for input variables in partial-expanded modules ... Since input variables are defined in the parent of the module where they are declared, this particular case ends up straddling over a module boundary: the EvalContext belongs to the parent while the node's own absolute address belongs to the child. The DynamicExpand implementation of the expander node already knows how to wire that up (the same way as for the fully-expanded equivalent) and so we don't need to do anything particularly special in this function, but it does mean that we need to provide some placeholder repetition data to use in case the definition expression refers to each.key, each.value, or count.index. For now we're using the "totally-unknown" repetition data that just sets all three symbols to unknown values. In future it would be nice to improve the precision here so that e.g. each.value can be treated as invalid when used in a call that doesn't set for_each, but that would require propagating the call configuration into this graph node and we don't yet have the needed information in the code that generates this node, so we'll save the more disruptive rework to allow that for a later change.	2 years ago
Martin Atkins	a55b0b39de	core: Placeholder values for local values in partial-expanded modules ... Since local value evaluation is largely identical between the fully- and partially-expanded cases, this factors out that handling into a shared function and makes the two graph node Execute functions just thin wrappers around it. The error-handling behavior is intentionally marginally different: it now always registers the local value result in the named values state, even on error, but uses cty.DynamicVal as a placeholder when an error prevents returning anything more precise than that. Nothing depends on that detail because downstream nodes don't get to execute when an upstream returns an error, but this approach reduces the number of possible outcomes and thus makes this marginally easier to follow. This also includes some modernization of the unit tests for TestNodeLocalExecute, so that it no longer relies on shimming functions from the Terraform v0.12 transition.	2 years ago
Martin Atkins	507cccef76	core: Placeholder values for output values in partial-expanded modules	2 years ago
Martin Atkins	079021df1b	terraform: Graph nodes can belong to partial-expanded module prefixes ... The new interface GraphNodePartialExpandedModule is a mutually-exclusive alternative to GraphNodeModuleInstance for graph nodes that represent the unbounded set of as-yet-unknown instances sharing a common known module prefix. For nodes that implement this interface, their Execute and DynamicExpand methods will receive an EvalContext that is configured to perform expression evaluation using safe placeholder values instead of using the real state and plan, since (once implemented in future commits) the graph nodes of this sort will be used for situations where we're deferring part of the plan until we have more information to use while planning.	2 years ago
Martin Atkins	42f012bee4	terraform: GraphWalker interface supports partial-expanded module addrs ... Nothing calls this yet, because we don't yet have an interface for a graph node to declare that it belongs to a partially-evaluated module prefix address. That will follow in later commits.	2 years ago
Martin Atkins	641837df7b	terraform: EvalContextBuiltin supports partial-expanded module instances ... Previously an EvalContextBuiltin could be associated either with no module at all or with a fully-qualified module instance, depending on whether each graph node implements the interface required to announce association with a particular module instance. For supporting partial-expanded module prefixes we now need a third mode where the context is associated with an addrs.PartialExpandedModule address, which conceptually represents an unbounded set of possible module instances that share a common known address prefix. The new type evalContextScope serves as a sum type which represents these three different situations. A nil value of that interface type represents no scope at all, whereas the two implementations of that type represent the two different possible scope types. Both scope types can produce an addrs.Module that they represent, allowing some degree of shared code between the two cases as long as no full instance addresses are required. The most important part of this change is that method EvaluationScope now uses a different implementation of lang.Data when the context scope is a partial-expanded module address. That implementation only returns placeholders that approximate what we expect all instances of the affected modules to have in common, in the hope of still catching some downstream errors even though full evaluation is being deferred to a future run. We currently have no means for a graph node to announce itself as belonging to a partially-expanded module address, and so in practice this new mode is not yet reachable. Future commits will teach the graph walker to be able to recognize and handle graph nodes that need this new treatment, making their DynamicExpand/Execute methods use this new scope type.	2 years ago
Martin Atkins	39a6f3a6db	terraform: a lang.Data impl for unexpanded modules ... When we're evaluating expressions inside a module that's beneath a partially-expanded prefix, we need to use placeholder values that describe only what we know to be true for all possible instances within that prefix, which requires quite a different reference evaluation strategy than we'd use in a fully-expanded module instance. evaluationPlaceholderData will therefore substitute for evaluationStateData in such cases. It is associated with an unbounded set of possible module instances sharing a known module instance prefix, and uses placeholder data generated by special graph nodes representing unexpanded objects, instead of finalized data coming from the main state or plan. As of this commit, the new type is not used at all. In subsequent commits we'll teach terraform.EvalContextBuiltin to support working under unexpanded module prefixes, and then this new lang.Data type will be part of the implementation of its expression-evaluation methods in that case.	2 years ago
Martin Atkins	3040deac66	terraform: Evaluator.StaticValidateReferences ... We previously had the StaticValidateReferences method implemented on the evaluationStateData type directly, but really the only information it needs directly from that object is the static module path, with everything else just coming from the wrapped Evaluator. That means that we can instead implement this as a method of Evaluator that is thinly wrapped by the prior evaluationStateData method. The guts of that method are functions that don't really depend on either of the two objects as a whole, so thus further turns them into just plain unexported functions that take the data they need as arguments. This commit doesn't achieve anything other than some light refactoring, but it will become more important in a subsequent commit that will add an additional implementation of lang.Data for evaluating references in expressions beneath an incompletely-expanded module. Both of those implementations can safely share the same implementation of StaticValidateReference though, since that method doesn't consider any dynamic expansion by definition anyway.	2 years ago
HenriBlacksmith	49663bfc33	terraform fmt: add .tfmock.hcl as a supported file extension (#34580) ... * terraform fmt: add .tfmock.hcl as a supported file extension * terraform fmt: add test cases for .tfmock.hcl files formatting * fix: update test to run on .tfmock.hcl files	2 years ago
Brian Flad	c7a44bfc9a	Support Private State with MoveResourceState (#34575) ... This change ensures that providers receive the source private state and can store potentially differing private state as part of a move, rather than always copying the source private state to the target. This functionality has not yet been released and therefore there are no compatibility concerns.	2 years ago
Martin Atkins	baa0f7805e	terraform: Modules can opt in to allowing unknown_instances ... When the unknown_instances language experiment is active, Terraform will accept unknown values in count and for_each arguments for resource, data, and module blocks. The unknown-ness of the expansion will be registered with the instance expander for later use, but much of the rest of the modules runtime is not yet equipped to deal with that situation, and so as of this commit the experiment will just cause some broken behavior if used. There are therefore no integration tests for this behavior just yet, because there's no reasonable expected behavior for such tests to assert. Behavior when the experiment is not enabled should remain unchanged. Proper handling of the unknown-expansion situation will develop over subsequent commits, along with integration tests once there's enough in place to write them, with this experiment being concluded only after all of that work has completed.	2 years ago
Martin Atkins	ae2a64a3ad	terraform: count and for_each evaluation permitting unknown values ... This is currently an opt-in argument, with no callers (except some tests) using it. Therefore this should not change any externally-visible behavior yet. Future commits will gradually incorporate support for modules and resources whose expansion isn't yet known, which will then cause planning of anything downstream of them to be deferred to a future run.	2 years ago
Martin Atkins	78e2e20157	experiments: "unknown_instances" is a current experiment ... This doesn't do anything yet as of this commit, but in future commits it will gate the possibility for count and for_each arguments to have unknown values, which will then cause affected objects to have their planning deferred to a future run.	2 years ago
Martin Atkins	b90b71768c	terraform: EvalContext.LanguageExperimentActive ... This exposes the set of active language experiments to graph node Execute and DynamicExpand methods, so that they can vary their behavior when certain experiments are active.	2 years ago
Martin Atkins	fe87334239	terraform: Stub nodes for named values in unexpanded modules ... This is early work toward supporting the handling of named values inside incompletely-expanded module prefixes, which is not yet possible but will become possible in future once we allow unknown values in count and for_each expressions inside module blocks. These new stub nodes don't do anything yet. The goal here is just to start staking out in preparation for future work, since support for unknown values in expansion arguments will arrive over quite a few later commits.	2 years ago
James Bardin	c4a2f74054	Merge pull request #34567 from hashicorp/jbardin/handling-instance-value-marks ... apply schema marks to returned instance values	2 years ago
James Bardin	8994e914b7	add sensitive attributes to test json output	2 years ago
James Bardin	8655b08b19	fix sensitive_attributes in test ... Add the missing sensitive_attributes to the test state, and update the output to reflect the new `"checks"` attribute name.	2 years ago
James Bardin	15ead7bce7	comment/debuging cleanup	2 years ago
James Bardin	57dad8d48d	apply schema marks to returned instance values ... The original sensitivity handling implementation applied the marks from a resource schema only when decoding values for evaluation. This appeared to work in most cases, since the resource value could only be used elsewhere in the configuration by references that would be returned from the evaluator. However, this approach left holes in the handling of the instance values where some marks may have been inserted from its own references to sensitive value, but the instance's own sensitive attributes were left unmarked. This was most noticeable in the state storage, where only sensitive references were listed in `sensitive_attributes`, leaving the actual sensitive attributes unmarked. The same problems would arise in the plan artifacts too, with the change `After` values missing attributes that should be sensitive, and the correction to the sensitive attributes depending on being decoded again during evaluation. Rather than depending on a value to be round-tripped through an encoding/decoding cycle via evaluation in order to be correctly marked, we need to apply the schema marks to all new values returned by a provider. This is added to the `ReadResource`, and `PlanResourceChange` paths to ensure values are consistently marked. We can then remove the re-insertion of the schema marks from the evaluator, because the value it sees should be correctly marked in all cases. Notably we don't need to do this for `Import`, because that value is never stored or referenced, -- an `ImportResource` call always consists of a followup `ReadResource` call, and there is no need to strip and re-apply the same marks. We also don't need to separately apply the schema marks after `ApplyResourceChange`, because they are the same marks we already stored in the plan `After` value (which should always be correct now that we insert them after `PlanResourceChange`).	2 years ago
Liam Cervante	9658f9df6b	mocking overrides: default to concrete empty object when values are missing (#34563)	2 years ago
Liam Cervante	430970c02b	terraform test: Fix crash when file level variables reference variables. (#34531) ... * terraform test: Fix crash when referencing variables within the file level variable block * also allow functions within variables blocks * add tests	2 years ago
Martin Atkins	0994e6fbf9	stacks: The terraform.workspace attr is not available in Stacks ... The terraform.workspace attribute is a rare example of a CLI- and Cloud- specific concern bleeding into the Terraform language, and it can only really have meaning when used in the traditional Terraform workflow because otherwise there's no workspace to return the name of. In Stacks any variations between instances of a module must be created through input variables. Within Terraform Cloud in particular it's also possible to use stack-level input variables that are assigned different values from different stack deployments, and thus an author can recreate the effect of terraform.workspace using a stack-level input variable that has a different value for each deployment. This is one of the few cases where the Terraform module language differs in stacks compared to traditional Terraform. Any module that makes use of terraform.workspace will need to be generalized to use input variables instead before it can be used within a stack component. Prior to this change, references to terraform.workspace from a module used in a stack component would just panic altogether, because the stacks runtime doesn't provide the object that the workspace name would be taken from. Now we'll return a user-oriented error instead.	2 years ago
Martin Atkins	9851cd456e	terraform: decide module instances using new API ... We've been gradually improving the design of how we keep track of "named values" such as output values, but the expression evaluator for output values was still doing some things in more manual/bespoke way, rather than making use of the new abstractions. We'll now use a combination of instances.Expander and namedvalues.State as the source of truth for which instances exist for a given module call and what output values each of those instances have. The configuration remains the decider for which output value names are declared, but the final result associated with each of the declared output values is tracked by namedvalues.State. This also removes the temporary namedvals GetOutputValuesForModuleCall method we added as a stopgap to allow introducing the namedvals.State API without such a disruptive rewrite of our output value handling. We have no further need for that helper because instances.Expander already knows which instances should exist for each module call, and the configuration knows which output values should exist in the result, and so namedvals only needs to be able to return one final output value result at a time, via namedvals.State.GetOutputValue. With all of the tricky inline logic factored out of this part of the evaluator, the TestEvaluatorGetModule test becomes considerably simpler since it's no longer the evaluator's responsibility to choose between various different sources for the module output values depending on the situation, and instead we just need to set the evaluator and the instance expander up in a realistic way, with the correct handling of both of those utilities already being covered by this package's main integration tests.	2 years ago
Martin Atkins	0c3a581ff0	instances: Expander.ExpandAbsModuleCall ... This is a similar idea to Expander.ExpandModule but for situations where we already know exactly which containing module we're evaluating inside, and thus we can just pluck out the leaf instance keys of that specific dynamic call, rather than the full recursive expansion of every containing module. Expander.ExpandModule is useful when implementing DynamicExpand for a graph node because main graph nodes always represent static configuration objects, but this new Expander.ExpandAbsModuleCall is more appropriate for use during expression evaluation of references to a module call because in that case we'll know which specific module instance address we're using as the evaluation scope. A future commit will actually use this new method from the expression evaluator in the modules runtime.	2 years ago
Martin Atkins	d37436a39a	addrs: ModuleInstance.AbsCall ... This is just a variation of the pre-existing ModuleInstance.Call that returns its result as a single value of type AbsModuleCall. This should really have been the signature of ModuleInstance.Call in the first place, but it took us some time to realize that we would benefit from an absolute address type for module calls themselves as opposed to the instances they imply once expanded, and so AbsModuleCall didn't exist at the time we originally wrote ModuleInstance.Call. Perhaps one day we'll update all existing callers of ModuleInstance.Call to use ModuleInstance.AbsCall instead, but for now we'll be pragmatic and keep both to avoid causing unnecessary churn.	2 years ago
Martin Atkins	f3c48314ab	addrs: AbsModuleCall.StaticModule ... This new method calculates the static Module address corresponding to the receiver, effectively discarding any instance keys present in the containing module instance path.	2 years ago
Brian Flad	3b4964270f	internal/command/jsonprovider: Remove root jsonfunction object from function output (#34536) ... Previously, the `providers schema -json` output would include the root object from `metadata functions -json`. This object had its own `format_version` property, which would be confusing with the root `format_version` property already present. This change still uses the `jsonfunction` package for consistency between cty and provider function JSON handling, but removes that extra object, instead making `functions` directly a mapping of names to signatures/definitions. This also adds a code comment to hint maintainers that jsonprovider format versioning is tied to jsonfunction format versioning. Example output prior to change: ```jsonc { "format_version": "1.0", "provider_schemas": { "registry.terraform.io/bflad/framework": { // ... "functions": { "format_version": "1.0", "function_signatures": { "example": { "description": "Echoes given argument as result", "summary": "Example function", "return_type": "string", "parameters": [ { "name": "input", "description": "String to echo", "type": "string" } ] } } } } } } ``` Example output after change: ```jsonc { "format_version": "1.0", "provider_schemas": { "registry.terraform.io/bflad/framework": { // ... "functions": { "example": { "description": "Echoes given argument as result", "summary": "Example function", "return_type": "string", "parameters": [ { "name": "input", "description": "String to echo", "type": "string" } ] } } } } } ```	2 years ago
Lauren	6d9b3b2cd7	call Colorize() on CLI output	2 years ago
Martin Atkins	7d2d4dec5e	stackeval: When being destroyed, component instance result comes from plan ... Because we treat dependency edges as reversed when a component instance is being destroyed, the final result (an object representing output values) for a component instance being destroyed must not depend on anything else in the evaluation graph, or else we'd cause a promise self-reference as the downstream component tries to configure itself based on our outputs. As a special case then, for a component instance being destroyed we take the planned output values directly from the plan, relying on the fact that the plan phase sets them to the prior state output values in that case, and therefore the result for such a component is available immediately without blocking on any other expression evaluation during the apply phase. This combines with several previous commits to create a first pass at handling ordering correctly when planning and applying a full destroy. This commit also incorporates some fixes and improvements to stackeval's apply-time testing helpers, which had some quirks and bugs when first added in a recent commit. One of those problems also revealed that the raw state loader was not resilient to a buggy caller setting a state entry to nil instead of removing it altogether, and that mistake seems relatively easy to make (as I did here in the test helper) so we'll tolerate it to make it possible to recover if such a bug does end up occurring in real code too.	2 years ago
Martin Atkins	dcb176a557	stackeval: A Main for applying knows the plan it's applying	2 years ago
Martin Atkins	c06ad051a1	stackeval: Respect inter-component dependencies during apply ... Before we start any apply-time actions for a particular component, we'll block until other components' apply are complete. In the normal case a component instance waits until its dependencies have been applied. However, if component instances are being destroyed then they instead wait for their _dependents_ to complete being applied, since a component must outlive all other components that depend on it.	2 years ago
Martin Atkins	c345cde93c	stackeval: Extended utilities for plan and apply testing ... These helpers make it easier to write our tests because the plan and apply phases both work in a callback-based fashion where they gradually emit events, and that's not a very convenient API for test code to interact with. This exposes some more details about the planning results, and also adds a new similar helper for the apply phase. We'll make use of both of these in future commits.	2 years ago
James Bardin	4d1499b559	Merge pull request #34525 from hashicorp/jbardin/unknown-errors ... Add error diagnostics when receiving an unknown value from `ReadResource` or `UpgradeResourceState`	2 years ago
James Bardin	d8a335f520	add unknown val error for MoveResourceState	2 years ago
Liam Cervante	9246b3a994	stacks: on module load convert relative paths to absolute (#34523)	2 years ago
Martin Atkins	4a0d06c13e	terraform test: Report skipped runs in JUnit XML output ... Previously we were just ignoring skipped runs completely, but JUnit XML has some elements/attributes for describing those and so we'll populate those too now.	2 years ago
Martin Atkins	b43ddd8ff6	terraform test: Experimental JUnit XML reporting ... This adds an experimental new option -junit-xml=FILENAME for the "terraform test" command. When specified, it writes a JUnit XML report to the specified filename once the test run is complete, while continuing to report test progress in the UI in the usual way. This is only experimental for now because it remains to be seen if this particular mapping to the JUnit XML schema is actually useful in real software -- this format is woefully underdocumented and implemented slightly differently by each consumer -- and so we might change this significantly before stabilizing it, or remove it altogether if it turns out that there's no useful mapping to JUnit XML here. Hopefully those who are interested in JUnit XML reports will try this experiment against their favorite JUnit XML-consuming software and report back whether the report is presented in a helpful way. It's a de-facto convention for JUnit XML to be reported separately to a file, rather than replacing the normal test run output, since tools that consume this format tend to present its results in a separate and less prominent place than the output of the command itself. This option is designed to follow that convention for consistency with various other software that produces this format. The implementation here is intentionally pretty minimal and simplistic just as a starting point for gathering feedback. The main priority is that it be easy to evolve this based on feedback and to remove it altogether if we decide not to stabilize this at all. If this does become stabilized, it might deserve being factored out into a separate package so that we can minimize the amount of logic embedded directly inside the views package, and it will certainly need some unit tests to represent what we've committed to supporting in future versions.	2 years ago
James Bardin	105b2044d5	remove leftover debug output	2 years ago
James Bardin	ef44fd604e	error when UpgradeResourceState return unknown value	2 years ago
James Bardin	0b4e468de6	error when ReadResource returns unknown value	2 years ago
Brian Flad	1298fcd412	Add missing function deprecation_message to JSON output and website documentation (#34520) ... Reference: https://github.com/hashicorp/terraform/pull/34450	2 years ago
James Bardin	bc945f22eb	Merge pull request #34515 from hashicorp/jbardin/provider-function-validation ... Add validation for provider function results	2 years ago
James Bardin	5c7b6614f5	add Validate to providerFunctionImpurePlan test ... In normal operation a Validate always precedes Plan, so add a check for that phase in the Plan test.	2 years ago
James Bardin	a5337b3b20	remove global results table state ... In the case of now possible long-running terraform processes, we don't want the cache to grow indefinitely. Move the handling of the results into the terraform package, and inject the shared table during the walk into the `BuildFunction` wrapper.	2 years ago
Liam Cervante	0ca03ecf08	Extend refactoring package to support cross-provider moves (#34501) ... * Extend refactoring package to support cross-provider moves * implement provider cache * make generate	2 years ago
Liam Cervante	7d143388f3	Add support for the cross resource type move operation in the proto schema (#34480) ... * Update proto schema and provider interfaces with support for moved across resource type RPCs * address comments * remove unused functions * remove support for flatmap format	2 years ago
James Bardin	94d64364a4	test provider function consistency	2 years ago
James Bardin	a3aa517589	store and verify provider functions calls in plan ... Store the hashed function calls within the plan file, so that Terraform can validate the results during apply as well. The error won't be as good, since we don't have access to the prior results to help debugging, but it is very helpful to indicate when a function returned an incorrect result rather than show that the resource attempted to apply a different value from what was originally planned.	2 years ago
James Bardin	b3c5590f01	Merge pull request #34450 from hashicorp/jbardin/provider-functions-json-schema ... Add functions definitions to the `providers schema -json` output	2 years ago
James Bardin	2e74fec583	add optional Summary field to function json	2 years ago
Graham Davison	57ec131e80	Ignores `AccessDenied` errors when listing bucket with default prefix	2 years ago
Graham Davison	40e593ddc1	Adds constant for default workspace prefix	2 years ago
Martin Atkins	3c14eeb945	stackeval: Make some provisioners available to stack components ... This makes the built-in "remote-exec" and "file" provisioners available for use in the modules that implement stack components. These are both relatively easy and low-risk to include because they are builtins and don't require anything from outside of Terraform itself. For now this intentionally excludes local-exec because we'll want to think about what constraints we want to put on it, if any, to help ensure we can meet the goal of stack configurations being portable between different execution environments without significant modification, and our current stacks execution environment doesn't guarantee the availability of any external software _at all_. The motivation for adding this now is just to give some better feedback when someone uses a module using one of these provisioners, since otherwise they'll see just a confusing generic error message from the modules runtime about the provisioners not being available. I expect we'll revisit this later and consider expanding it to at least include local-exec, and _maybe_ external provisioner plugins, although that's more questionable because the provisioner plugin mechanism is incredibly legacy and doesn't have any way to work outside of local Terraform CLI usage today. There are no tests here yet because these provisioners are not mockable and would depend on having an SSH or WinRM server to connect to. Later we should ponder how to make this more testable, which might mean making another part of the system responsible for actually providing the provisioner factories and thus our tests here can use fakes. The goal here is just to get this done in a relatively lightweight way for better feedback during preview though, so we're not yet ready to make significant time investments here.	2 years ago
Martin Atkins	6071e06f1a	tfstackdata1: DynamicValueFromTFStackData1 decodes sensitive marks	2 years ago
Alisdair McDiarmid	1d3f863f2b	stackruntime: Support sensitive component inputs ... Components can emit sensitive values as outputs, which can be consumed as inputs to other components. This commit ensures that such values are correctly processed in order to pass their sensitivity to the modules runtime.	2 years ago
Alisdair McDiarmid	fc75657113	terraform: Support sensitive input variable values ... The stacks runtime interacts directly with the modules runtime's planning operations, rather than through the usual CLI paths. As a result, root module input variable values can be marked as sensitive upon entry. This commit adds support for such marked values to the modules runtime and the `plans.Plan` type. This is sufficient for stacks, which does not use the planfile serialization, but we may in future choose to serialize these decoded marks also.	2 years ago
Alisdair McDiarmid	e4b319401e	stacksruntime: Add sensitive outputs tests	2 years ago
Martin Atkins	3961c18420	stackeval: Return an error if a module contains a provider config ... When using stacks the provider configurations belong in the stack configuration rather than inline in the individual modules. Shared modules with inline provider configurations has been a deprecated legacy practice for many years now, but traditional Terraform continued to support it for backward-compatibility with older modules despite the significant downsides of doing so. Stacks now finally removes that capability, since it isn't straightforward to continue supporting it once we've made the stacks runtime be responsible for instantiating and configuring providers.	2 years ago
Martin Atkins	a51c034cc3	stackeval: Include component configurations in our static walks ... This means both that the validate walk can now describe static problems in the component's module tree, and that we'll catch such problems earlier in the planning phase and thus avoid reporting them repeatedly in cases where a component block uses for_each to declare multiple instances. This includes a fix to a bug in StackConfig.Components, which was incorrectly using the input variable declarations as the source for its result, instead of the component declarations.	2 years ago
Martin Atkins	a3cd4a11ce	stackeval: Use relative, slashy paths in module-related diagnostics ... Until we've updated the module config loader to be sourcebundle-aware and thus return proper source addresses, this will at least make the paths we show in diagnostics a little less verbose, and more consistent across platforms.	2 years ago
Martin Atkins	a4d61733f6	stackplan: Include extra info in raw component instance plan ... We'll now track the planned action, the component addresses we depend on, and the planned output values.	2 years ago
Martin Atkins	25a514f846	stackeval: Populate planned component instance more thoroughly ... We'll now track a more realistic Action, the components that the component instance depends on, and the planned output values.	2 years ago
Martin Atkins	524da4f278	stackeval: Applyable objects have a set of required components ... To figure out the required order in which we'll apply the plans for all components we need to know how data flows between them. We'll use what's added here during the plan phase to record in the plan which components depend on which other components, and then the apply phase will use that coarse information to schedule the individual component apply operations into a suitable order. None of that is implemented here though, and will follow in future commits. This commit includes new documentation about the apply scheduling approach which includes some mechanisms that are not actually yet included in this commit, but will follow shortly after. This is just a pragmatic compromise to avoid spending time authoring short-lived partial documentation drafts for the intermediate steps while still keeping these increments small enough for practical review.	2 years ago
Martin Atkins	5bfdb12098	stackaddrs: Absolute references and referenceables ... This allows us to talk about references between expressions in absolute terms, taking into account the stack where a particular expression would be resolved. This isn't an appropriate representation for references like each.key, since those require a more specific scope than just a stack, but that's okay because those contextual reference types can't depend on anything other than what they are embedded inside anyway, and so we never need to consider them when we're doing global reference analysis.	2 years ago
Martin Atkins	00761a9f70	stackeval: ApplyChecker is now Applyable ... We chose this name originally to communicate that implementations are only responsible for checking that an apply was successful, but in future commits this interface will also gain the additional responsibility of helping to gather the information required to understand the dependency relationships between components that will then drive the scheduling of the apply actions during the apply phase.	2 years ago
Martin Atkins	11bb10ba72	stackeval: Find references in arbitrary expressions and bodies ... Along with full expression/body evaluation, we'll also need to be able to determine what an expression or body refers to without evaluating it, so that we can use references to infer dependency relationships between significant side-effects in the apply phase, such as the relative ordering of applying the changes for different components.	2 years ago
Martin Atkins	8cb51f415b	collections: go-cmp helpers for the collection types ... A downside of using custom collection types is that go-cmp doesn't support them automatically, and so we need to help it out a little by providing additional options. An additional awkwardness is that go-cmp does all of its work at runtime using reflection, at which point the generic types have all been erased and lowered to many separate concrete types. Therefore we need some helper functions to produce a dynamically representation using interface types, cautiously exposing some internal details of these types only for go-cmp's use. The dynamic adapter here unfortunately means that the compiler likely won't be able to optimize away CmpOptions in non-test builds, but we'll accept that for now since the cost of that inert data and code is relatively small. If it turns out to be a problem then we'll need to find a different strategy, but hopefully not.	2 years ago
Martin Atkins	306b9008c4	stackeval: Clean some debug junk in ComponentInstance ... I apparently missed this when I was preparing my previous round of commits in this area. Mea culpa.	2 years ago
Liam Cervante	d2502265dc	removed: child modules should be removed if they are within a removed module (#34487)	2 years ago
Nick Fagerlund	9d7737b2fe	Merge pull request #34447 from hashicorp/nf/dec23-grpc-metadata-cloudplugin ... Cloudplugin: Pass configuration via gRPC metadata	2 years ago
Nick Fagerlund	ff62192819	Adjust CloudPluginConfig doc comments	2 years ago