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
Passing a provider for an MLC's children via pulumi.Provider
results in error
#12430
Labels
area/sdks
Pulumi language SDKs
customer/feedback
Feedback from customers
customer/lighthouse
Lighthouse customer bugs
impact/regression
Something that used to work, but is now broken
kind/bug
Some behavior is incorrect or out of spec
language/go
p1
Bugs severe enough to be the next item assigned to an engineer
resolution/fixed
This issue was fixed
Milestone
Comments
justinvp
added
kind/bug
Some behavior is incorrect or out of spec
area/sdks
Pulumi language SDKs
p1
Bugs severe enough to be the next item assigned to an engineer
language/go
impact/regression
Something that used to work, but is now broken
labels
Mar 14, 2023
This is related to #11520 I think we want the following behavior: If a provider is passed to an MLC with
|
justinvp
added
customer/lighthouse
Lighthouse customer bugs
customer/feedback
Feedback from customers
labels
Mar 14, 2023
abhinav
added a commit
that referenced
this issue
Mar 14, 2023
In #12296, we started correctly interpreting the Provider argument per other SDKs. but this introduced a regression: the Provider field is now set for resources with mismatched types. This results in a scenario where a provider foo for package X is passed to a resource bar with package Y, with the intent of plumbing it to bar's descendants, but bar attempts to incorrectly use the provider directly. foo := NewXProvider() bar := NewYThing("bar", Provider(foo)) // ... baz := NewXThing("baz", Parent(bar)) // should use foo This worked previously, but with #12296, this fails because NewYThing attempts to use Provider foo directly. To fix this, we need to prevent NewYThing from using a provider that does not match the package that it belongs to. We had to make a similar change to the Python SDK in #12292. https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927 The regression test is specific to remote component resources per #12430, but the issue would be caused even for normal component resources before this. Resolves #12430
Fixing in #12433. |
abhinav
added a commit
that referenced
this issue
Mar 14, 2023
In #12296, we started correctly interpreting the Provider argument per other SDKs. but this introduced a regression: the Provider field is now set for resources with mismatched types. This results in a scenario where a provider foo for package X is passed to a resource bar with package Y, with the intent of plumbing it to bar's descendants, but bar attempts to incorrectly use the provider directly. foo := NewXProvider() bar := NewYThing("bar", Provider(foo)) // ... baz := NewXThing("baz", Parent(bar)) // should use foo This worked previously, but with #12296, this fails because NewYThing attempts to use Provider foo directly. To fix this, we need to prevent NewYThing from using a provider that does not match the package that it belongs to. We had to make a similar change to the Python SDK in #12292. https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927 The regression test is specific to remote component resources per #12430, but the issue would be caused even for normal component resources before this. Resolves #12430
bors bot
added a commit
that referenced
this issue
Mar 15, 2023
12426: filestate/internal: Use stack reference, not name r=abhinav a=abhinav filestate backend currently operates exclusively with stack names. All its internal pass around just the stack name, and nothing else. This makes it a bit difficult to add project support to the backend. This is a refactor in advance of adding project support, changing the internals of filestate to pass a stack reference around. It inspects the reference directly for all its operations. Note: This contains no behavioral changes. Name and FullyQualifiedName currently both return just the stack name. In a future change, once project name is incorporated into the object, FullyQualifiedName will be able to return `organization/$project/$name`. Change extracted from #12134 12433: sdk/go: Don't use Provider for type if package doesn't match r=abhinav a=abhinav In #12296, we started correctly interpreting the Provider argument per other SDKs. but this introduced a regression: the Provider field is now set for resources with mismatched types. This results in a scenario where a provider foo for package X is passed to a resource bar with package Y, with the intent of plumbing it to bar's descendants, but bar attempts to incorrectly use the provider directly. foo := NewXProvider() bar := NewYThing("bar", Provider(foo)) // ... baz := NewXThing("baz", Parent(bar)) // should use foo This worked previously, but with #12296, this fails because NewYThing attempts to use Provider foo directly. To fix this, we need to prevent NewYThing from using a provider that does not match the package that it belongs to. We had to make a similar change to the Python SDK in #12292. https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927 The regression test is specific to remote component resources per #12430, but the issue would be caused even for normal component resources before this. Resolves #12430 12435: Pin CI to Node 19.7.x to avoid hitting assert in 19.8.0 r=abhinav a=justinvp Node 19.8.0 was released ~5 hours ago and we're hitting an internal assert. Pin to 19.7.x to unblock CI until we understand what's going on with 19.8.0. Part of #12434 Co-authored-by: Fraser Waters <fraser@pulumi.com> Co-authored-by: Abhinav Gupta <abhinav@pulumi.com> Co-authored-by: Justin Van Patten <jvp@justinvp.com>
bors bot
added a commit
that referenced
this issue
Mar 15, 2023
12433: sdk/go: Don't use Provider for type if package doesn't match r=abhinav a=abhinav In #12296, we started correctly interpreting the Provider argument per other SDKs. but this introduced a regression: the Provider field is now set for resources with mismatched types. This results in a scenario where a provider foo for package X is passed to a resource bar with package Y, with the intent of plumbing it to bar's descendants, but bar attempts to incorrectly use the provider directly. foo := NewXProvider() bar := NewYThing("bar", Provider(foo)) // ... baz := NewXThing("baz", Parent(bar)) // should use foo This worked previously, but with #12296, this fails because NewYThing attempts to use Provider foo directly. To fix this, we need to prevent NewYThing from using a provider that does not match the package that it belongs to. We had to make a similar change to the Python SDK in #12292. https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927 The regression test is specific to remote component resources per #12430, but the issue would be caused even for normal component resources before this. Resolves #12430 12435: Pin CI to Node 19.7.x to avoid hitting assert in 19.8.0 r=abhinav a=justinvp Node 19.8.0 was released ~5 hours ago and we're hitting an internal assert. Pin to 19.7.x to unblock CI until we understand what's going on with 19.8.0. Part of #12434 Co-authored-by: Abhinav Gupta <abhinav@pulumi.com> Co-authored-by: Justin Van Patten <jvp@justinvp.com>
bors bot
added a commit
that referenced
this issue
Mar 15, 2023
12433: sdk/go: Don't use Provider for type if package doesn't match r=abhinav a=abhinav In #12296, we started correctly interpreting the Provider argument per other SDKs. but this introduced a regression: the Provider field is now set for resources with mismatched types. This results in a scenario where a provider foo for package X is passed to a resource bar with package Y, with the intent of plumbing it to bar's descendants, but bar attempts to incorrectly use the provider directly. foo := NewXProvider() bar := NewYThing("bar", Provider(foo)) // ... baz := NewXThing("baz", Parent(bar)) // should use foo This worked previously, but with #12296, this fails because NewYThing attempts to use Provider foo directly. To fix this, we need to prevent NewYThing from using a provider that does not match the package that it belongs to. We had to make a similar change to the Python SDK in #12292. https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927 The regression test is specific to remote component resources per #12430, but the issue would be caused even for normal component resources before this. Resolves #12430 Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
bors bot
added a commit
that referenced
this issue
Mar 15, 2023
12433: sdk/go: Don't use Provider for type if package doesn't match r=Frassle a=abhinav In #12296, we started correctly interpreting the Provider argument per other SDKs. but this introduced a regression: the Provider field is now set for resources with mismatched types. This results in a scenario where a provider foo for package X is passed to a resource bar with package Y, with the intent of plumbing it to bar's descendants, but bar attempts to incorrectly use the provider directly. foo := NewXProvider() bar := NewYThing("bar", Provider(foo)) // ... baz := NewXThing("baz", Parent(bar)) // should use foo This worked previously, but with #12296, this fails because NewYThing attempts to use Provider foo directly. To fix this, we need to prevent NewYThing from using a provider that does not match the package that it belongs to. We had to make a similar change to the Python SDK in #12292. https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927 The regression test is specific to remote component resources per #12430, but the issue would be caused even for normal component resources before this. Resolves #12430 Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
bors bot
added a commit
that referenced
this issue
Mar 15, 2023
12433: sdk/go: Don't use Provider for type if package doesn't match r=Frassle a=abhinav In #12296, we started correctly interpreting the Provider argument per other SDKs. but this introduced a regression: the Provider field is now set for resources with mismatched types. This results in a scenario where a provider foo for package X is passed to a resource bar with package Y, with the intent of plumbing it to bar's descendants, but bar attempts to incorrectly use the provider directly. foo := NewXProvider() bar := NewYThing("bar", Provider(foo)) // ... baz := NewXThing("baz", Parent(bar)) // should use foo This worked previously, but with #12296, this fails because NewYThing attempts to use Provider foo directly. To fix this, we need to prevent NewYThing from using a provider that does not match the package that it belongs to. We had to make a similar change to the Python SDK in #12292. https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927 The regression test is specific to remote component resources per #12430, but the issue would be caused even for normal component resources before this. Resolves #12430 Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
bors bot
added a commit
that referenced
this issue
Mar 15, 2023
12433: sdk/go: Don't use Provider for type if package doesn't match r=Frassle a=abhinav In #12296, we started correctly interpreting the Provider argument per other SDKs. but this introduced a regression: the Provider field is now set for resources with mismatched types. This results in a scenario where a provider foo for package X is passed to a resource bar with package Y, with the intent of plumbing it to bar's descendants, but bar attempts to incorrectly use the provider directly. foo := NewXProvider() bar := NewYThing("bar", Provider(foo)) // ... baz := NewXThing("baz", Parent(bar)) // should use foo This worked previously, but with #12296, this fails because NewYThing attempts to use Provider foo directly. To fix this, we need to prevent NewYThing from using a provider that does not match the package that it belongs to. We had to make a similar change to the Python SDK in #12292. https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927 The regression test is specific to remote component resources per #12430, but the issue would be caused even for normal component resources before this. Resolves #12430 Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/sdks
Pulumi language SDKs
customer/feedback
Feedback from customers
customer/lighthouse
Lighthouse customer bugs
impact/regression
Something that used to work, but is now broken
kind/bug
Some behavior is incorrect or out of spec
language/go
p1
Bugs severe enough to be the next item assigned to an engineer
resolution/fixed
This issue was fixed
The following Go program previews as expected using v3.56.0 of the Go SDK:
main.go:
go.mod:
Output:
However, upgrading the pulumi SDK to v3.57.1 (
github.com/pulumi/pulumi/sdk/v3 v3.57.1
) results in the following error during preview:The error message is deceiving... it's coming from:
pulumi/sdk/go/common/resource/plugin/provider_plugin.go
Line 1250 in 477e0c9
We've seen this before in #11316. When passing an AWS provider to an MLC, the engine is trying to use that provider to construct the MLC. But the AWS provider doesn't have an implementation of Construct for the MLC, and it's failing earlier when trying to call Construct on the AWS provider because the AWS provider currently says it doesn't support secrets.
Workaround
A workaround is to pass the provider via
pulumi.Providers
(plural) rather thanpulumi.Provider
(singular). The plural variant is intended for passing providers for a component's children.The text was updated successfully, but these errors were encountered: