Skip to content
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

Support explicit providers for packaged components #11520

Closed
3 of 6 tasks
justinvp opened this issue Dec 2, 2022 · 3 comments
Closed
3 of 6 tasks

Support explicit providers for packaged components #11520

justinvp opened this issue Dec 2, 2022 · 3 comments
Assignees
Labels
area/component-packages aka multi-language components area/sdks Pulumi language SDKs customer/feedback Feedback from customers customer/lighthouse Lighthouse customer bugs kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed

Comments

@justinvp
Copy link
Member

justinvp commented Dec 2, 2022

SDKs don't currently support specifying an explicit provider to use when constructing a packaged component (MLC).

This hasn't been too limiting so far as all our first-party component packages aren't currently configurable, but that likely won't always be true, and certainly users may want to offer component packages that are configurable via explicit providers.

This limitation also doesn't work well with the feature to disable default providers. If you configure your stack to enforce that no resource should use a default provider (e.g. pulumi:disable-default-providers: ["*"]), and your stack is using packaged components, you'll get an error associated with the packaged component (e.g. Default provider for 'awsx' disabled. 'awsx:ec2:Vpc' must use an explicit provider.) that you can't do anything about aside from changing disable-default-providers to list the providers (like "aws") rather than the "*" catch-all.

Languages


Vote on this issue by adding a 👍 reaction.

@justinvp justinvp added kind/bug Some behavior is incorrect or out of spec area/sdks Pulumi language SDKs area/component-packages aka multi-language components labels Dec 2, 2022
@AaronFriel
Copy link
Member

Seems like we ought to handle this in the engine - based on parent - to limit the number of resource options that component authors need to handle correctly.

It would be even better if we were able to automatically apply parent and provider[s] resource options to resources registered during a Construct call.

@Frassle
Copy link
Member

Frassle commented Jun 22, 2023

It would be even better if we were able to automatically apply parent and provider[s] resource options to resources registered during a Construct call.

I'd prefer this. I think we can do this pretty easily by spinning up a new ResourceMonitor for the construct call to enforce parent and then get the rest for free by making the engine do propagation for provider/providers.

bors bot added a commit that referenced this issue Jul 13, 2023
13282: [sdk/nodejs,python] Add support for explicit providers for packaged components r=justinvp a=justinvp

Add support for explicit providers for packaged components in the Node.js and Python SDKs.

Go already supports it. Node.js briefly supported it with #11093, but the change was reverted in #11509 due to an issue. Python has never supported it.

The PR is broken up into multiple commits for easier reviewing.

Fixes #13074
Part of #11520

Co-authored-by: Justin Van Patten <jvp@justinvp.com>
@justinvp justinvp self-assigned this Sep 5, 2023
@justinvp justinvp added the resolution/fixed This issue was fixed label Sep 5, 2023
@justinvp
Copy link
Member Author

justinvp commented Sep 5, 2023

I'm going to close this as fixed as the customer request was addressed with #13282.

I've opened separate issues to track investigating and fixing (if needed) the remaining SDKs:

@justinvp justinvp closed this as completed Sep 5, 2023
github-merge-queue bot pushed a commit that referenced this issue Nov 18, 2023
Support returning plain values from methods.

Implements Node, Python and Go support.

Remaining:

- [x] test receiving unknowns
- [x] acceptance tests written and passing locally for Node, Python, Go
clients against a Go server
- [x] acceptance tests passing in CI
- [x] tickets filed for remaining languages
   - [x] pulumi/pulumi-yaml#499
   - [x] pulumi/pulumi-java#1193
   - [x] pulumi/pulumi-dotnet#170 

Known limitations:

- this is technically a breaking change in case there is code out there
that already uses methods that return Plain: true

- struct-wrapping limitation: the provider for the component resource
needs to still wrap the plain-returning Method response with a 1-arg
struct; by convention the field is named "res", and this is how it
travels through the plumbing

- resources cannot return plain values yet

- the provider for the component resource cannot have unknown
configuration, if it does, the methods will not be called
- Per Luke #11520 this might not
be supported/realizable yet

<!--- 
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. -->

Fixes #12709

## Checklist

- [ ] I have run `make tidy` to update any new dependencies
- [ ] 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.
-->
- [ ] 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. -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/component-packages aka multi-language components area/sdks Pulumi language SDKs customer/feedback Feedback from customers customer/lighthouse Lighthouse customer bugs kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Projects
None yet
Development

No branches or pull requests

4 participants