The hand-rolled invoke code in the Kubernetes Python SDK is not
expecting empty dicts for empty results. Instead, it has code that
checks for `None`.
In general, we want to keep the behavior of returning empty dicts rather
than `None` for empty results, as this aligns with the behavior of other
SDKs (Node.js and Go) and is actually the original behavior of the
Python SDK (it regressed unintentionally in the v2 timeframe).
We're updating the Kubernetes Python SDK to be resilient to either
getting an empty dict or `None` for invokes with empty results.
Additionally, to maintain compat with older versions of the Kubernetes
Python SDK, we'll special case those invoke tokens. When an invoke's
result is empty and the token is one of the Kubernete's function tokens,
we'll return `None` rather than the empty dict.
Fixes#14508
When an empty struct is returned from an invoke, the Python SDK was
returning None, which causes the following error to be raised from
generated provider Python SDKs when calling the invoke:
```
AssertionError: get can only be used with classes decorated with @input_type or @output_type
```
This is because the Python SDK is returning None if the return value
isn't truthy, roughly:
```
ret_obj = getattr(resp, "return")
if ret_obj:
return ret_obj
return None
```
However, an empty struct isn't truthy, so we're returning None in that
case, and generated provider Python SDKs can't handle that.
Other SDKs like the Node.js and Go SDKs don't have this problem.
This commit fixes the issue by removing the `if ret_obj` check, as it's
not necessary. In practice, `ret_obj` is always going to be an instance
of `struct_pb2.Struct` because all monitors (CLI and mock) return an
instance, though the instance may be empty, which is ok.
Fixes#13985
This PR replaces all the dependabot PRs with a single commit that
updates all relevant go.mod files.
This resolves 3 Dependabot alerts on golang.org/x/net including a
moderate severity alert.
This change adds the missing `default` arg to `Config.get_secret`
method, for consistency with the other `get_secret_<type>` methods that
have a `default` arg.
Fixes#12271
<!---
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 https://github.com/pulumi/pulumi/issues/13997.
It would be a little nicer if every input type _actually_ implemented
the `Mapping` interface, but that trying to do that turned into a much
deeper fix than this one.
## 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. -->
- [x] 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. -->
Updates to the latest versions of
google.golang.org/genproto and google.golang.org/grpc
in all submodules in the repository.
This is necessary because in a recent change,
genproto split out some of its subpackages into independent submodules.
(https://github.com/googleapis/go-genproto/issues/1015)
As a result of this, some users may see the error:
```
google.golang.org/genproto/googleapis/rpc/status: ambiguous import: found package google.golang.org/genproto/googleapis/rpc/status in multiple modules:
google.golang.org/genproto v0.0.0-20230410155749-daa745c078e1 (/home/runner/go/pkg/mod/google.golang.org/genproto@v0.0.0-20230410155749-daa745c078e1/googleapis/rpc/status)
google.golang.org/genproto/googleapis/rpc v0.0.0-20230725213213-b022f6e96895
```
Because pu/pu is using 20230410155749,
which has googleapis/rpc as a subpackage,
but another dependency references the independent submodule (20230725213213),
so the system doesn't know which module to use for the import path,
google.golang.org/genproto/googleapis/rpc/status.
This is a problem for codegen tests and ProgramTest-based tests
for Pulumi Go programs that do not have a go.mod in the test directory.
This issue was encountered by @thomas11 while attempting to upgrade
dependencies in pulumi-docker (pulumi/pulumi-docker#700).
The grpc upgrade is necessary because the current version of grpc
also pulls the outdated version of genproto.
We used to test that various errors we're written out to the user in
these langhost tests, but at some point those test were removed (I
suspect because we stopped printing them to stderr).
This adds in the ability to check for a log message in the engine
diagnostics stream, and makes use of that in one of the tests.
Add support to the core SDKs for reporting resource source positions.
In each SDK, this is implemented by crawling the stack when a resource
is registered in order to determine the position of the user code that
registered the resource.
This is somewhat brittle in that it expects a call stack of the form:
- Resource class constructor
- abstract Resource subclass constructor
- concrete Resource subclass constructor
- user code
This stack reflects the expected class hierarchy of "cloud resource /
component resource < customresource/componentresource < resource".
For example, consider the AWS S3 Bucket resource. When user code
instantiates a Bucket, the stack will look like
this in NodeJS:
new Resource (/path/to/resource.ts:123:45)
new CustomResource (/path/to/resource.ts:678:90)
new Bucket (/path/to/bucket.ts:987:65)
<user code> (/path/to/index.ts:4:3)
In order to determine the source position, we locate the fourth frame
(the `<user code>` frame).
13463: Fix links to outputs docs r=cnunciato a=cnunciato
Fixes some broken links pointing to the Inputs & Outputs docs.
Fixes#13461.
Co-authored-by: Christian Nunciato <chris@nunciato.org>
Fixes https://github.com/pulumi/pulumi/issues/7029
For some reason the python RPC serializer explictly disallowed tuple,
despite python codegen outputing types using `Sequence` rather than
`List` suggesting that `tuple` would be acceptable.
A previous attempt to fix this in 5dd813ea47 didn't fully address the problem when there are more complex parent/child relationships with components.
This change fully addresses the problem by using the same cycle detection logic used elsewhere for local components. We now check for cycles up-front and exit early.
When a resource depends on a local component resource, rather than setting the component resource itself as a dependency, each of the component's descendants is added as a dependency. This can lead to hangs when cycles are introduced.
For example, consider the following parent/child hierarchy, where `ComponentA` is the parent of `ComponentB` and `ComponentB` is the parent of `CustomC`:
ComponentA
|
ComponentB
|
CustomC
If `ComponentB` specifies it has a dependency on `ComponentA`, the following takes place as part determining the full set of transitive dependencies:
1. `ComponentA` is a component resource so it isn't added as a dependency, its children are.
2. `ComponentA` has one child: `ComponentB`
3. `ComponentB` is a component resource so it isn't added as a dependency, its children are.
4. `ComponentB` has one child: `CustomC`, a custom resource.
5. Since `CustomC` is a custom resource, it is added to the set of dependencies.
6. We try to await its URN, but we'll never get it because `RegisterResource` hasn't yet been called for it. And we hang waiting.
To address this, skip looking at a component's children if it is the component from which the dependency is being added.
In the example, with the fix, at step 3 the dependency expansion will stop: we won't look at `ComponentB`'s children because we're adding the dependency from `ComponentB`.
PR feedback
12374: whoami: Add --json flag, expose everything in Auto API r=abhinav a=mrod-io
<!---
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
* Adds `--json` flag to `pulumi whoami` (CLI)
* Adds `url` and `organizations` to WhoAmIResult in NodeJS, Go and Python (automation API)
I sanity tested the auto api in the 3 runtimes and the cli output looks like:
```bash
$ pulumi whoami -j
{
"user": "me",
"organizations": [
"me",
"company"
],
"url": "https://app.pulumi.com/me"
}
```
<!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. -->
Fixes # https://github.com/pulumi/pulumi/issues/10356
## Checklist
<!--- Please provide details if the checkbox below is to be left unchecked. -->
- [x] 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 Service,
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 Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
12397: Changelog and go.mod updates for v3.57.1 r=abhinav a=pulumi-bot
bors merge
Co-authored-by: Matthew Rodrigues <matthew.rodrigues@starburstdata.com>
Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
Co-authored-by: github-actions <github-actions@github.com>
12275: Add stack tag support for python automation api sdk r=justinvp a=mrod-io
<!---
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
Adds support for tagging stacks with the Python automation API.
<!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. -->
Fixes # (issue)
* https://github.com/pulumi/pulumi/issues/11936 (Python support)
## Checklist
<!--- Please provide details if the checkbox below is to be left unchecked. -->
- [x] 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 Service,
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 Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
Co-authored-by: Matthew Rodrigues <matthew.rodrigues@starburstdata.com>
It's currently possible in Pulumi to pass a ProviderResource
as a Provider option to a ComponentResource.
The ComponentResource will record the Provider for later,
and propagate it to its child resources.
This is currently the behavior in [all SDKs except Python][1].
[1]: https://github.com/pulumi/pulumi/issues/12161#issuecomment-1446864847
The reason this didn't work was because in Python's
providers merging logic, we use the incorrect package name
when saving the provider.
Instead of using the package name reported by the provider,
we were using the package name of the current resource
(the ComponentResource in this case).
To fix this, verify that the package name of the provider
matches the package name of the resource we're building.
If it doesn't, we will still save the provider
for child resources.
Resolves#12161
The MergeResourceOptions test was incorrectly invoking
the static method ResourceOptions.merge as an instance method.
This issue was reported by the type-checker.
Upgrades all go.mod files to v0.7.0 of golang.org/x/net.
This will take care of the disparate dependabot updates we're receiving
for these files.
See also https://github.com/pulumi/pulumi/security/dependabot/151
Refs CVE-2022-41723
12071: sdk/py/StackReference: Add get_output_details r=abhinav a=abhinav
This is the Python equivalent to the StackReference.GetOutputDetails
method and accompanying type added to the Go SDK in #12034.
This will allow users of the Python SDK to fetch outputs from stack
references directly--without going through an Output type.
Refs #10839, #5035
Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
This is the Python equivalent to the StackReference.GetOutputDetails
method and accompanying type added to the Go SDK in #12034.
This will allow users of the Python SDK to fetch outputs from stack
references directly--without going through an Output type.
Refs #10839, #5035
When the `await RPC_MANAGER.rpcs.pop()` explodes,
the traceback is for `RPC_MANAGER.rpcs.pop()`, e.g.
```
error: Program failed with an unhandled exception:
Traceback (most recent call last):
File "/opt/hostedtoolcache/pulumi/3.43.1/x64/pulumi-language-python-exec", line 179, in <module>
loop.run_until_complete(coro)
File "/opt/hostedtoolcache/Python/3.10.9/x64/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
return future.result()
File "[..]/venv/lib/python3.10/site-packages/pulumi/runtime/stack.py", line 126, in run_in_stack
await run_pulumi_func(lambda: Stack(func))
File "[..]/venv/lib/python3.10/site-packages/pulumi/runtime/stack.py", line 51, in run_pulumi_func
await wait_for_rpcs()
File "[..]/venv/lib/python3.10/site-packages/pulumi/runtime/stack.py", line 73, in wait_for_rpcs
await RPC_MANAGER.rpcs.pop()
RecursionError: maximum recursion depth exceeded
```
This isn't super helpful in debugging these errors.
RPC_MANAGER already tracks uncaught excpetions from such RPCs
but wait_for_rpcs doesn't account for these until aftewards.
This changes wait_for_rpcs to reproduce the original tracebacks
when it encounters errors in waiting for RPCs.
The included test verifies that the more helpful traceback is produced.
Refs #11887
11741: Add json_loads to python sdk r=Frassle a=Frassle
<!---
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. -->
Partner method to json_dumps.
## Checklist
<!--- Please provide details if the checkbox below is to be left unchecked. -->
- [x] 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 Service,
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 Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
Co-authored-by: Fraser Waters <fraser@pulumi.com>
11543: Update Pulumi codegen to net6.0 r=Frassle a=Frassle
<!---
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. -->
.NET Core 3.1 is out of support on December 13th:
https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core
We've already stopped testing on .NET Core 3.1, and program gen has been targeting only 6.0 for a while now as well.
This updates sdkgen to only 6.0 as well.
We'll need to ensure the version number in pkg/codegen/dotnet/gen.go matches the version number that https://github.com/pulumi/pulumi-dotnet/pull/10 release as.
## Checklist
<!--- 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 Service,
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 Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
Co-authored-by: Fraser Waters <fraser@pulumi.com>
I used the node SDK as inspiration for this change - there were a few things
we were doing differently in python (specifically handling all cases in
the outer layer of `massage` rather than allowing for more fine-grained
control in a `massage_complex` function like in node. We also take the stack
concept from the node SDK to resolve the immediate issue of duplicate outputs.
When resolving a resource's outputs, if an output value is missing (and it's not a preview), the SDK will see if there was an input prop of the same name as the output prop and use that input value as the value for the output. This can be problematic when the input prop's type isn't the same as the output prop's type. If the input value is a `dict` and the type of the output cannot be converted from a `dict`, then the SDK currently raises an `AssertionError`, which causes `pulumi up` to fail. This is inconsistent with the other language SDKs, which don't error during `pulumi up` in such cases.
This change changes the behavior of the Python SDK to not error when attempting to use an input value for the output value when there is a type mismatch. Instead of raising an error, `None` is returned, which is the same value that would be used if there had been no input value available to fill-in.