-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
feat(stacks): add CLI config in RPC API handshake #35146
Conversation
chore(stacks): protobuf generation feat(stacks): implement cred source interface refactor: use handshake for service disco refactor: err handling refactor: rename capability field
5eceeea
to
2350c29
Compare
Calling this "CLI Configuration" in the rpcapi context (where we've presented this as a way to "bypass" Terraform CLI and get to Terraform Core directly) seems a little idiosyncratic, but I must admit I'm not sure what else I'd call the general container for "CLI-configuration-like things". The only non-weird alternative that comes to my mind is to just put this new I also don't really feel strongly about the overall oddity in the first place. I mention it just in case you want to consider it. I've no objection to accepting the idiosyncratic name if that feels like the best of the available options. 🤷♂️ |
I'm okay with either deviating away from "CLI" naming or hoisting those fields to ClientCapabilities. Some ideas that come to mind: rename the message struct to a generic |
Looking again at the full protobuf schema (rather than just the parts visible in the diff! 😅) I see one more possibility: We could add Of all of these options I think the one I've described in this comment seems to get us what we need in as simple a way as possible and so I favor this one, but again I'm not wedded to it. |
Yeah adding this new field to the HandShake Request makes a lot of sense to me. I previously headed down that direction until I came across this comment which made me reconsider using "Capabilities" instead. terraform/internal/rpcapi/plugin.go Lines 59 to 68 in 7012371
Update: Nevertheless, I'm on board with either solution that would better position the protocol for future revisions 😄. |
I expect I probably wrote that comment, and if so I imagine I wrote it with the same partial mental context I had when I was initially commenting on this PR, before I read the full schema and remembered that we also have the Sorry for inadvertently leading you down a strange path! I note that this comment is in a function that only has access to the |
All paths lead to the desired destination given enough time (Cheesy I know) 😄. But made the revisions as discussed 🎊. |
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.
This looks good to me! Thanks for the patience while we moved all the little bits around. 😀
I have one little note inline. If you agree with me and change it, please just go ahead and merge the updated version without another round of review, since it's a very minor thing and so not worth another round-trip.
Sounds good and no worries at all, been a fun iteration cycle 😄. |
Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch. |
This PR adds support for including fields typically found in the Terraform CLI configuration in the RPC API handshake. This allows us to include global configuration arguments that impact the RPC API session without requiring instrumentation for each RPC service. The new Config struct currently supports only service discovery credentials, but it can be expanded in the future.