-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add Paramaterize to provider interface #16174
Conversation
Changelog[uncommitted] (2024-05-15) |
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.
Thanks for getting this in!
b09b25e
to
acd01ae
Compare
As part of merging, I would really like to see the contract semantics as comments in // Parameterize takes either a string array of command line inputs or a value embedded from sdk generation.
rpc Parameterize(ParameterizeRequest) returns (ParameterizeResponse) {} This is an ok description for
These descriptions can change over time, but they should reflect the current understanding of how these methods are used. We have historically struggled with documenting our gRPC methods clearly and this is a good opportunity to fix that. |
Can do, I'm still trying to work out how we're going to handle multiple versions of the same sub-package at the moment. I think we need it for CRDs and I think it requires the CRUD methods to be updated as well. |
acd01ae
to
c4d475e
Compare
<!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the bare bones changes required to update the provider interface for parametrization. Nothing in the engine, sdks, cli, or codegen makes use of these new methods yet. But providers team can start building on top of this interface. Note that this is subject to change, while this is _likely_ the right design for parametrised providers there is a chance that we need to edit this interface before GA release. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
c4d475e
to
4b0e684
Compare
// Providers can be parameterized with either multiple extension packages (which don't define their own provider | ||
// resources), or with a replacement package (which does define its own provider resource). |
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.
How does the engine know if a provider is being parameterized by an extension package or a replacement provider? As I understand it, the engine will need to treat extended and replaced providers very differently.
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.
Yeh it will be part of the register resource call.
Description
This is the bare bones changes required to update the provider interface for parametrization. Nothing in the engine, sdks, cli, or codegen makes use of these new methods yet.
But providers team can start building on top of this interface. Note that this is subject to change, while this is likely the right design for parametrised providers there is a chance that we need to edit this interface before GA release.
Checklist
make tidy
to update any new dependenciesmake lint
to verify my code passes the lint checkgofumpt
make changelog
and committed thechangelog/pending/<file>
documenting my change