PSS: Refactor how we handle unmanaged providers, add support for using dev_override#38269
Draft
SarahFrench wants to merge 7 commits intomainfrom
Draft
PSS: Refactor how we handle unmanaged providers, add support for using dev_override#38269SarahFrench wants to merge 7 commits intomainfrom
SarahFrench wants to merge 7 commits intomainfrom
Conversation
We can handle this like checking if a provider is reattached, though this needs to be a method on the Meta as that's where details of dev overrides is stored. HOWEVER we don't always have access to the Meta (see StateStoreConfigState's Validate method). Instead, the description of the state store config could report what way the provider is supplied to code using the config. I'll refactor to that in the next commit.
SarahFrench
force-pushed
the
pss/support-dev-overrides
branch
from
8cbd98d to
49bb568
Compare
SarahFrench
commented
Mar 12, 2026
internal/command/meta_backend.go
Outdated
| // The provider is not built in and is being managed by Terraform | ||
| // This is the most common scenario, by far. | ||
| var vDiags tfdiags.Diagnostics | ||
| pVersion, vDiags = getStateStorageProviderVersion(c, opts.Locks) |
Member
Author
There was a problem hiding this comment.
TODO: Can we move all this switch statement into this method? This is easier to understand, but still repeated in the code a few times.
Also, I want to ensure that duplicate warnings aren't happening.
…ut how the state store provider has been supplied to Terraform
…ovider supply' data in the StateStore struct and use it when determining provider version and calculating the hash value. This streamlines code where we have to check if a provider is builtin/reattached/dev override. By doing that once early on and reusing the outcome from that process we can streamline downstream code. After this commit there'll be paired changes that allow the backend state file to use this data too.
…epresentation of a store. StateStoreConfigState now contains ProviderSupplyMode. This is set when the backend state is saved during init, and makes it easier to create plans when non-managed providers are used (see PlanData method). The supply mode data is written in the final JSON file describing the state store, which can be used in diagnosing GH issues.
…include new, necessary provider_supply_mode data.
…version into the `getStateStorageProviderVersion` function
SarahFrench
force-pushed
the
pss/support-dev-overrides
branch
from
b3db7dd to
a8235e3
Compare
SarahFrench
added
the
no-changelog-needed
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Context
Terraform needs to handle unmanaged providers specially in the context of the PSS feature. We want to record the version of the provider used for PSS in the backend state file, but Terraform only has access to version data when the provider is managed by Terraform. Version data is missing when a provider is reattached or a developer override, and a builtin provider isn't versioned separately to the core binary as a whole.
This PR adds support for dev_override providers, as Terraform previously could only handle reattached and builtin providers. It also refactors how data about whether a provider is managed or not is stored in memory and handled during commands. See section below for details.
Reviewer!
This PR covers a bunch of separate but coupled change (e.g.
StateStoreandStateStoreConfigState). I recommend going commit by commit and/or engaging me via Slack, if needed.This PR
Originally this PR was intended to add support for developer overrides, another type of unmanaged provider that could be used for PSS. While implementing that I wanted to simplify how we handle all the types (builtin, reattached, dev override) so I made the
StateStorestruct describing the state_store block carry around information inside about how the provider has been supplied to Terraform. This prevented downstream code needing to determine this, sometimes repeatedly.After doing this I realised that there was still a problem of determining provider version when describing the state store provider in plan file data. Determining whether a provider is a developer override requires access to the Meta, which we don't have at the time we record plan data, so I realised we need to update the
StateStoreConfigStatestruct to also carry info about how the PSS provider has been supplied to Terraform.This then raised the question of whether that data should be included in the contents of a backend state file, or deliberately omitted. I thought that including the data would be useful when diagnosing issues. Prior to this backend state files implicitly described using a non-managed provider by storing
nullversion data, but this change makes that description more explicit. Also, the new data wouldn't be used to trigger state migrations but could be useful for providing extra info to practitioners when performing a migration between managed and non-managed providers for PSS.Target Release
1.15.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