[pull] main from hashicorp:main #4
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Co-authored-by: runephilosof-karnovgroup <101270124+runephilosof-karnovgroup@users.noreply.github.com>
…loud-colorize add changelog entry for #34473
Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>
Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>
…s`, and `encode_expr` (#34891)
…-Guide docs: Terraform style guide
This new document is a mixture of context that was previously just institutional knowledge held by me and a few other Terraform Core members, and of new information I've learned while practicing dependency upgrades under our new multi-module repository layout. I've documented this as a starting point for those who are completely new to the codebase, and for those who were already familiar but haven't yet performed upgrades in the new multi-module layout. This all still remains slightly in flux because I'm using real dependency upgrades to practice different interactions between the different modules, and so this is likely to evolve as we learn more, but we need to have at least some initial docs on this around in case we need to perform upgrades in an emergency situation where I am not around to assist directly.
stacks: add deferred to protobuf
…-overrides Interpolate environment variables when configuring dev_overrides
The concept behind deferred actions is that various objects (resources, data
sources, modules, stack components) can end up being *deferred*, meaning that
we're unable to produce an actionable plan for them and intend to run the *rest*
of the plan to completion and apply it without taking action on those objects,
which will have to wait for another future plan.
For the most part, we only *find out* about the kinds of absences that force
deferral at the time of *graph walk.* That's because deferral is caused by
unknown values in count/for_each, absent dependencies reported by the provider,
or dependency on something that got deferred, none of which can really be know
at graph construction.
Also, we don't always want deferral to be an available option -- for the time
being, we want to preserve existing behavior in the modules runtime ("normal
terraform") while enabling deferral in Stacks.
So, *things that happen during graph walk need to know whether they can defer.*
(And if not, they'll throw an error if they hit such an absence.) That means the
top-level signal that deferral is enabled (which should arrive as part of the
PlanOpts) needs to make it all the way down into the graph walk methods.
The graph walk methods generally have access to an EvalContext, and EvalContext
conveniently gives you access to a Deferred tracker, the pointer to which is
shared across all related EvalContexts. So, the Deferred will be what tells you
whether you can defer.
We're still iterating on the ability to defer unplannable changes to a later plan. However, instead of enabling it via a "contagious" experimental feature switch that can bubble up from any module, it's now behind a per-plan option in the PlanOpts struct. That option travels a winding path into the internals (see previous commit), and node execution logic can then access it during the plan walk via the `Deferred.DeferralAllowed()` method. This commit updates the spot where we switch between the deferral yea/nay code paths to respect this top-level plan option rather than the experiment flag.
Ultimately, we want deferred actions to always be enabled for Stacks. However, it's not ready to turn on yet, as it currently regresses other features. So, adding a top-level option that flows through to the main terraform.PlanOpts field will allow us to enable it selectively in tests while we sort out various behaviors.
Not all paths might be apply-able when transforming this cty.Value in the provider implementation. The generic PlanResourceChange mock implementation can get by for now without dealing with complex nested values. Tests that need something specific will add a PlanResourceChangeFn.
It's possible to have mark paths which can't be applied verbatim to values, and comparing marks we've collected from a provider schema to those as applied to a value may differ. This is mostly apparent when applying a sensitive mark to a value nested within a set, where the set must adopt the mark, which will no longer be tracked directly by the set element.
Marks for values within nested computed collections won't be present in the plan, because they can't be applied to the unknown outer value. Add in any schema marks which may be missing during apply, but still retain the marks form the plan since they may have others which came from configuration.
We no longer have a use case for comparing marks directly, and it seems that there should be no reason to, remove the dedupe function. The rest of the calls were superfluous, and only there to ensure the function was used consistently.
Always add all marks to plan and apply values, then compare marks from the values
Now that deferred actions is a top-level per-plan option, here's a lil command-line option for turning it on! - It's called `-allow-deferral`. - It is ONLY legal to use if this is an experimental build, i.e. compiled with `go build -ldflags "-w -s -X 'main.experimentsAllowed=yes'"` or the like. Implementation notes: The design constraint here was, "please avoid having to change the build infrastructure or alter the function of every args parsing function". So, since `extendedFlagSet()` doesn't have access to the var that says we're in an experimental build, I had to move the validation for that particular flag to later in the process, when we're building the operation request.
Plan and refresh already had this, but apply would deref a nil opReq and panic.
We previously had a strange assortment of different versions, but it's typically best to have all of these fixed to the same version because otherwise there can be quirky interactions where e.g. an interface type has changed without updating its implementors, etc. This intentionally does not yet upgrade the contrib packages or exporters because they imply other dependency upgrades that we want to perform separately first, so we can avoid changing too much at once.
…ions Allow enabling deferred actions in PlanOpts
…atures of gcs backend (#34895) * Update Sensitive Data in State page to describe encryption features of gcs backend * Update website/docs/language/state/sensitive-data.mdx Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com> * Remove bullet points --------- Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Add the deferred changes into the plan * add copywrite headers
|
Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch. |
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )