-
Notifications
You must be signed in to change notification settings - Fork 97
Resource Identity: Add identity data to RPCs needed to store/read from state #1112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -96,6 +98,17 @@ func (s *Server) DeleteResource(ctx context.Context, req *DeleteResourceRequest, | |||
resp.Private = req.PlannedPrivate | |||
} | |||
|
|||
// If the resource supports identity pre-populate a null value. | |||
// TODO:ResourceIdentity: This should probably be prior identity, but we don't currently have that in the protocol. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we / did you already mention this to core?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did in the RFC here -> https://docs.google.com/document/d/1jvNfineZgXaKFP5djLkMxXKf9s6Xq-FzBV3p2jHGbiI/edit?disco=AAABe6K13yk
It's unclear whether planned_identity
will contain the prior_identity
value, but I think it's generally agreed upon that the prior identity will be provided in some fashion 😆
LGTM as well 👍🏽 |
The base branch was changed.
This PR allows a framework provider to store/read identity data for a managed resource (along with
Terraform v1.12.0-alpha20250312
). The RPCs implemented for this areReadResource
(Read
),PlanResourceChange
, andApplyResourceChange
(split in framework toCreate
/Update
/Delete
).I left some intentional TODOs for pieces of work I wasn't 100% sure of that should be resolved before we release stable
v1.15.0
.Generally, the flow of data through the packages (using protocol v5 as an example, it's the same for v6):
proto5server
(implements the RPC in plugin-go) =>fromproto5
(maps request from plugin-go types to fwserver types)proto5server
=>fwserver
(this is where any framework-specific logic is implemented for the RPC)fwserver
=>resource
(the actual provider code for the resource, like aws or azurerm)proto5server
=>toproto5
(maps response from fwserver types to plugin-go types)The other RPCs that are not needed to successfully test the happy path of
plan
/apply
workflow, these will be implemented in follow-up PRs:ImportResourceState
MoveResourceState
UpgradeResourceIdentity