terraform

Commit Graph

Author	SHA1	Message	Date
Roniece	95c947e7f4	Add ActionInvocationFromProto, call actioninvocationFromTFPlan	3 months ago
Mutahhir Hayat	ab6119fd90	Revert fix and instead update test expectation	3 months ago
Mutahhir Hayat	581fd6d550	Fix test with incorrect provider address	3 months ago
Mutahhir Hayat	e074b103dd	Revert unncessary change to get provider address	3 months ago
Mutahhir Hayat	946918220c	Read Action invocations from planfile	3 months ago
Mutahhir Hayat	547473364c	Expose Action Invocation conversion to Proto publicly	3 months ago
Daniel Schmidt	188eeac4ff	remove now obsolete ReadConfig on planfile	3 months ago
Daniel Banck	297ebd989e	Move some planfile tests To be able to read and build the configuration in planfile related tests, we need methods from the `terraform` package. This commit moves the test into that package to make testing easier.	3 months ago
Kristin Laemmert	70e074b8aa	chore (actions): rename LifecycleActionTrigger -> ResourceActionTrigger in plan and proto We'd previously removed all other references to "lifecycle" actions, which made this reference stand out. ResourceLifecycleActionTrigger is probably the most accurate name, but as this type just needs to be differentiated from InvokeActionTrigger I thought "resource" was enough (and I specifically wanted= to avoid lifecycle at all). I'm not super attached to the name, but I did think it would be clearer if we avoided Lifecycle as much as possible, since that's got some overlap with action subtypes. In this instance, we call it a LifecycleActionTrigger because it's come from the resource's `lifecycle` block. This doesn't directly relate to the concept of LifecycleActions - even if we expand the design to have multiple action types (for example generic and lifecycle actions), both those actions types would use this same Trigger struct.	3 months ago
Radek Simko	0fe906fa8c	make copyrightfix	3 months ago
Sarah French	f591872699	PSS: Allow pluggable state store configuration to be stored in a plan file (#37956 ) * refactor: Rename Meta's backendState field to backendConfigState This helps with navigating ambiguity around the word backend. The new name should indicate that the value represents a `backend` block, not a more general interpretation of what a backend is. * fix: Only set backendConfigState to synthetic object if it's nil due to a lack of data. Don't change it if pluggable state storage is in use. * feat: Enable recording a state store's details in an Operation, and using that data when creating a plan file. * fix: Include provider config when writing a plan file using pluggable state storage * fix: Having `backendConfigState` be nil may be valid, but it definitely isn't valid for `stateStoreConfigState` to be nil When backendConfigState is nil it means that an implied local backend is in use, i.e. there is no backend block in the config. * test: Add integration test showing that a plan command creates a plan file with the expected state_store configuration data * refactor: Apply suggestion from @radeksimko Co-authored-by: Radek Simko <radeksimko@users.noreply.github.com> * fix: Allow panics to occur if an unexpected implementation of `backend.Backend` is encountered when managing a state store * docs: Add code comment explaining the current situation with passing backend config state to downstream logic. In future this should be simplified, either via refactoring or changes affecting the implied local backend --------- Co-authored-by: Radek Simko <radeksimko@users.noreply.github.com>	6 months ago
Sarah French	9fb91c2229	PSS: Refactor Plan struct to reference `Backend` and `StateStore` via pointers, update calling code (#37946 ) * refactor: Update Plan struct's Backend field to be a pointer * fix: Add some refactorings or protections against nil pointers when accessing the Backend field on a Plan struct * refactor: Update Plan struct's StateStore field to be a pointer, update a nil check in calling code.	6 months ago
Kristin Laemmert	df113486a1	actions: remove references to action types, linked resources (#37616 ) * action renaming * actions: remove references to action types * actions: remove references to linked_resources or action types from the plan proto	9 months ago
Liam Cervante	866363ffff	actions: add invoke nodes to the graph (#37521 ) * actions: add invoke graph nodes * fix small bugs * add additional tests * remove whitespace * fix copyright headers * go generate * address comments	9 months ago
Daniel Schmidt	871d3ce64f	support sensitive values in action configuration	9 months ago
Daniel Schmidt	14c83aa7ee	allow reporting action invocations as deferred	9 months ago
Daniel Schmidt	219c31f4eb	action: move action trigger into nested struct this prepares the work on CLI / flag-driven invocations	9 months ago
Daniel Schmidt	27e58b32ca	properly handle actions without config	10 months ago
Daniel Schmidt	1bd8eb8629	save config value to planfile	10 months ago
Daniel Schmidt	fb0445faf2	allow language experiments for terraform show	10 months ago
Daniel Schmidt	c2b35e7ee7	remove duplicate place to store action invocations from plan	10 months ago
Daniel Schmidt	2654e4d7cd	add information for graph building into plan action invocations	10 months ago
Kristin Laemmert	0374f04424	Add ValidateActionConfig to provider interface, protocol & internal implementations (#37345 ) * Add ValidateActionConfig to provider interface and protocol * Update internal/provider-simple-v6/provider.go Co-authored-by: Daniel Schmidt <danielmschmidt92@gmail.com> --------- Co-authored-by: Daniel Schmidt <danielmschmidt92@gmail.com>	11 months ago
Kristin Laemmert	9256074c43	Actions in plan/changes (#37320 ) * Add actions to the plans and change * jsonplan - ignoring LinkedResources for now, those are not in the MVP * pausing here: we'll work on the plan rendering later	11 months ago
Sarah French	2349481b23	Update data stored in plan files to enable using PSS with saved plans (#37246 ) * Implement `ForPlan` method on `StateStoreConfigState`, add `Planner` interface * Rename `ForPlan` method to `Plan` * Allow plan files to contain information about state stores * Add code needed for representing a state store in the Plan struct, which is used when handling plan files * Add ability to read/write either a backend or state store's data in a plan file. Add some test coverage. * Update plan's `ProviderAddrs` method to include the provider used for PSS, if present * Split interfaces * Apply feedback from code review * Refactor `SetVersion` to use appropriate constructor * Split `ProviderAddrs` method test into two * Fix method call after rename * Fix test * Remove change to `(p Plan) ProviderAddrs()` We may re-add this when we implement PSS for use during apply commands with plan files Remove changes to test, now that the plan doesn't report the provider used for PSS anymore.	11 months ago
Sarah French	4d2d773634	Add and refactor test in the `planfile` package (#37245 ) * Refactor existing `TestTFPlanRoundTrip` test * Add new test for validation errors when writing a new plan file with `writeTfplan`	12 months ago
James Bardin	807e084130	final renaming for function results	1 year ago
James Bardin	a6ec17cb77	rename function results table Remove "provider" from the function results fields since it's not going to be exclusively used for providers any longer.	1 year ago
James Bardin	d016070564	move function results hashing to lang We need to abstract the function results verification to use internally too, so start by moving it out of the providers code.	1 year ago
Daniel Banck	0aa4ce972d	Add resource identities to plan file and JSON output (#36903 )	1 year ago
Samsondeen	c0a7ff235b	Apply some new go collection features (#36818 )	1 year ago
Daniel Schmidt	fec6e4b552	send resource identities to provider calls	1 year ago
James Bardin	384f2d4fab	update collections to use for-range method	2 years ago
James Bardin	257678fafb	final changes changes	2 years ago
James Bardin	bc750192e4	POC for always using decoded changes in core We should not need to encode and decode change values within core, since the encoded version is only technically needed for serialization. This pattern stems from the conversion to current changes system, but back then we did not have easy access to the correct schemas at the time to encode and decode the entire set of changes. Moving the core handling of changes to only use the decoded values will drastically improve evaluation efficiency, removing a round trip through encoded values for every resource reference.	2 years ago
Liam Cervante	87bbc47737	stacks: include plan mode in stacks plan format (#35405 ) * stacks: include plan mode in stacks plan format * fix tests * fix missed files	2 years ago
Liam Cervante	0f0414d484	Fix partial address representation in plan for deferred actions (#34966 ) * Fix partial address representation in plan * reflect new type in stacks	2 years ago
Liam Cervante	9b95898f63	stacks: emit events for deferred actions (#35325 ) * stacks: emit events for deferred actions * deferral allowed is always on * Update internal/rpcapi/stacks.go Co-authored-by: Daniel Schmidt <danielmschmidt92@gmail.com> --------- Co-authored-by: Daniel Schmidt <danielmschmidt92@gmail.com>	2 years ago
Liam Cervante	96da5e9f46	deferred actinos: add support for unknown ids in import blocks (#35300 )	2 years ago
Martin Atkins	641219bd19	plans: Track input variables that must be re-supplied during apply We'll use this to track what subset of the ephemeral input variables were set in the planning options, and which ones must therefore be re-supplied in the apply phase options. This new plan field is not yet populated anywhere. The uses of this will follow in subsequent commits.	2 years ago
Daniel Schmidt	59ead5356f	stacks: update RPC APIs with deferral information (#35125 ) * stacks: add deferred resource instance planned change to protobuf * stacks: add deferred resource instance to stack plan sequence * stacks: add planned change for deferred actions * stacks: refactor planned change resource instance planned moving the components out of the main function definition so that we can reuse the implementation for deferred resource instances which wraps the message used for PlannedChangeResourceInstancePlanned * stacks: track deferred changes in stackplan * add simple tests * fix tests * address comments --------- Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>	2 years ago
Martin Atkins	30e2fd6525	Handle marks a little more consistently In the very first implementation of "sensitive values" we were unfortunately not disciplined about separating the idea of "marked value" from the idea of "sensitive value" (where the latter is a subset of the former). The first implementation just assumed that any marking whatsoever meant "sensitive". We later improved that by adding the marks package and the marks.Sensitive value to standardize on the representation of "sensitive value" as being a value marked with _that specific mark_. However, we did not perform a thorough review of all of the mark-handling codepaths to make sure they all agreed on that definition. In particular, the state and plan models were both designed as if they supported arbitrary marks but then in practice marks other than marks.Sensitive would be handled in various inconsistent ways: dropped entirely, or interpreted as if marks.Sensitive, and possibly do so inconsistently when a value is used only in memory vs. round-tripped through a wire/file format. The goal of this commit is to resolve those oddities so that there are now two possible situations: - General mark handling: some codepaths genuinely handle marks generically, by transporting them from input value to output value in a way consistent with how cty itself deals with marks. This is the ideal case because it means we can add new marks in future and assume these codepaths will handle them correctly without any further modifications. - Sensitive-only mark preservation: the codepaths that interact with our wire protocols and file formats typically have only specialized support for sensitive values in particular, and lack support for any other marks. Those codepaths are now subject to a new rule where they must return an error if asked to deal with any other mark, so that if we introduce new marks in future we'll be forced either to define how we'll avoid those markings reaching the file/wire formats or extend the file/wire formats to support the new marks. Some new helper functions in package marks are intended to standardize how we deal with the "sensitive values only" situations, in the hope that this will make it easier to keep things consistent as the codebase evolves in future. In practice the modules runtime only ever uses marks.Sensitive as a mark today, so all of these checks are effectively covering "should never happen" cases. The only other mark Terraform uses is an implementation detail of "terraform console" and does not interact with any of the codepaths that only support sensitive values in particular.	2 years ago
Martin Atkins	ea60ca7d70	plans/planfile: Don't use deprecated "io/ioutil" package Everything from ioutil has been moved into other locations in modern Go. This particular package only used ioutil.ReadAll and ioutil.ReadFile, which have been replaced by io.ReadAll and os.ReadFile respectively.	2 years ago
Martin Atkins	6be3ddf9e7	planfile: Reject value marks that we cannot serialize The plan file format can only preserve the "sensitive" mark, but previously it was just silently treating any other mark as if it were the sensitive mark. Now we'll reject any other marks at serialization time. There are not currently any other marks used by the modules runtime and so in practice this cannot fail yet, but this is here to guard against misbehavior if we introduce new marks in future without considering whether and how they are to be serialized. (For any mark we choose not to serialize, it'll be the caller's responsibility to replace the values using unsupported marks with suitable unmarked placeholders.)	2 years ago
Daniel Schmidt	5b8f77d2a4	stacks: add deferred actions to plugin protocol We are moving the deferred reason from plans/deferring to providers to have a single representation of deferred reason to be used from providers to the plan. Using the plan's representation causes circular dependencies. Co-authored-by: Matej Risek <matej.risek@hashicorp.com>	2 years ago
Liam Cervante	28797e7938	Add the deferred changes into the plan (#34946 ) * Add the deferred changes into the plan * add copywrite headers	2 years ago
Martin Atkins	5f2eab6944	providerreqs: Provider requirement/version types in their own package As we previously found with "package addrs", any package that contains types used as identifiers or addresses tends to get imported from all over, which means that if we mix real logic with those types in the same package then a lot more packages end up depending indirectly on our external dependencies. In this case, the getproviders package depends on various things we need only during provider installation, such as the library we use for GPG signature verification. Lots of different packages in Terraform need to talk about provider requirements, but only the CLI layer actually needs to do provider installation, and so this commit splits the types we use to talk about requirements into a new package "providerreqs", which package getproviders then depends on. To keep the size of this diff relatively small to start I've left forwarding aliases in package getproviders, which means that not all of the callers needed to be updated all at once. This commit does update all of the packages that the remote state backends depend on though, because that then allows us to reduce the set of indirect dependencies for each of those backends. The nested module go.mod files show that this has disconnected the indirect dependencies on github.com/ProtonMail/go-crypto and on github.com/cloudflare/circl , both of which Terraform CLI uses only for provider installation.	2 years ago
CJ Horton	5a750561e6	round-trip check results through stack plans Components expect that check results will be round-tripped through the plan in order to update unknown check results during the apply. We hadn't wired this up for stack plans, resulting in panics when the apply tries to update a check status that doesn't exist.	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
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

1 2

85 Commits (f8fb61de12dea9ac94de3060a0d3e97ce9b5480b)