PSS: Add initial (incomplete) version of code changes to the init command for using pluggable state storage
#37321
Conversation
abf3b49 to
072096d
Compare
| if opts.StateStoreConfig != nil { | ||
| // state store has been parsed from config and is included in opts | ||
| var ssDiags tfdiags.Diagnostics | ||
| stateStoreConfig, cHash, _, ssDiags = m.stateStoreConfig(opts) | ||
| diags = diags.Append(ssDiags) | ||
| if ssDiags.HasErrors() { | ||
| return nil, diags | ||
| } | ||
| } else { | ||
| // backend config may or may not have been parsed and included in opts, | ||
| // or may not exist in config at all (default/implied local backend) | ||
| var beDiags tfdiags.Diagnostics | ||
| backendConfig, cHash, beDiags = m.backendConfig(opts) | ||
| diags = diags.Append(beDiags) | ||
| if beDiags.HasErrors() { | ||
| return nil, diags | ||
| } | ||
| } |
There was a problem hiding this comment.
A nuance worth highlighting is in this section is that m.stateStoreConfig(opts) behaves a bit differently to m.backendConfig(opts)
What's different: backendConfig will re-parse the config to look for a backend block if opts.BackendConfig is nil. In stateStoreConfig there is no re-parsing; it assumes that the calling code has already parsed the configuration in the module correctly and that any state_store config will be represented in opts.
What's similar: these two methods both combine config with override config (-backend-config CLI flag values) and do some high-level validation of the config. E.g. backendConfig checks that the backend type exists, and stateStoreConfig checks that the PSS is present in the state storage provider.
…arsed config. This can only be done once modules have been parsed and the required providers data is available. There are multiple places where config is parsed, into either Config or Module structs, so this needs to be implemented in multiple places.
…ore config. State store config can now be received via BackendOpts and there is rough validation of whether the config makes sense (does the provider offer a store with the given name?).
At this point there are no cases that actually handle the state store scenarios though!
…r implied local) project
…ath for adding a state store for the first time
…igrating to (implied) local backend
1e88968 to
81e0862
Compare
…and nested provider blocks
|
I found another test that can be added at this stage, but I think other tests in |
|
I've also realised while working on a stacked PR that this PR would make more sense pulling in commit d06b639, but it would make this PR a lot larger. I'll avoid cherry-picking it in for now. Without that commit, this PR's code is capable of determining the scenario that the working directory is in, but the code is currently unable to pass data about the state_store configuration block via the |
| case !foundReqProviderEntry && stateStore.Provider.Name == "terraform": | ||
| // We do not expect users to include built in providers in required_providers | ||
| // So, if we don't find an entry in required_providers under local name 'terraform' we assume | ||
| // that the builtin provider is intended. | ||
| return addrs.NewBuiltInProvider("terraform"), nil |
There was a problem hiding this comment.
Allowing this to be less explicit is aligned with #37234
(Stacked on top of #37278)
Context
This PR updates backend-related code that is hit by all Terraform commands that use a backend.
The Meta struct's
Backendmethod is used in most if not all Terraform commands. This method returns an operations backend that's used to run a given operation/command.That method invokes Meta's
backendFromConfigmethod, which uses the current configuration and the backend state file to either:initcommandThis code performs all these functions, and what it does is impacted by:
opt.Initset to true)This PR
This PR mostly updates code in
internal/command/meta_backend.goto handle the increasing number of possible combinations of prior state (backend state files) and current state (configuration) of a working directory. These different scenarios are handled in a largeswitchstatement inbackendFromConfigthat invokes scenario-specific logic implemented in separate methods.This PR adds new cases to that
switchstatement that are mostly empty and have no scenario-specific logic implemented. Instead, there are tests that assert that when a working directory's state resembles a given scenario then the corresponding case is invoked.Target Release
1.14.x
Rollback Plan
Changes to Security Controls
Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.
CHANGELOG entry