When a resource `dependsOn` a remote component, we were not correctly waiting on it, because we were skipping over waiting on comoponents, and only waiting on their custom resource children. For remote components, we do not know the children, but waiting on the remote component will always wait on all children.
Co-authored-by: Mike Metral <1112768+metral@users.noreply.github.com>
Adds initial support for resource methods (via a new `Call` gRPC method similar to `Invoke`), with support for authoring methods from Node.js, and calling methods from Python.
* Do not hang but propagate exception when it happens in resolve_outputs
* Add an integration test for the issue
* Better error message
* Add CHANGELOG_PENDING entry
* Update sdk/python/lib/pulumi/runtime/rpc.py
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
* Address PR feedback and tighten path param typing
* Given Windows builder is failing, allow 2x time for the test
* Give some more time to the Windows runner
* Attempt to solve differently
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
Rotating a passphrase requires that the old passphrase is available via
one of the `PULUMI_CONFIG_PASSPHRASE` or `PULUMI_CONFIG_PASSPHRASE_FILE`
environment variables. This confuses `readPassphrase` when reading a new
passphrase, since that function checks the aforementioned environment
variables prior to reading from the console. The overall effect is that
it is impossible to rotate the passphrase for a stack using the
passphrase provider. These changes fix this by always reading from the
console when rotating a passphrase.
This command converts an appdash trace into a pprof file for use with
`go tool pprof`. Spans are converted into stacks by sampling each root
span at a given rate and recording the stack of subspans at each sample.
These changes also replace the conditional addition of experimental and
debug commands with conditional visibility. Experimental and debug
commands will always be available, but will be hidden unless the
appropraite environment variables are set.
Co-authored-by: Levi Blackstone <levi@pulumi.com>
* Add trace proxying to fix sub-process trace collection when tracing to files
* Better func naming in test
* Avoid dealing with Windows path nightmare
* On Windows it is go.exe of course
* Rename operation to component to better align with existing trace output
Temporarily disable the new config secret warning to avoid unactionable warnings from provider `config` modules. We'll re-enable the warning when we've addressed that issue.
* Propagate workspace.Project metadata to plugin init
* Get to a working fix
* Propagate Root via plugin context
* Propagate root instead of yaml path
* Revert out unnecessary parameter propagation
* Root is now always absolute at this point; simplify code and docs
* Drop python conditional and propagate unused -root to all lang hosts
* Add tests that fail before and pass after
* Lint
* Add changelog entry
Fixes: #6286
When a user is using the passphrase provider and unsets the environment
variables that let them interact with the secrets provider, then would
get an error as follows:
```
▶ pulumi up -y -f
error: decrypting secret value: failed to decrypt: incorrect passphrase, please set PULUMI_CONFIG_PASSPHRASE to the correct passphrase
```
We are oging to change this error message to make it more obvious
to a user what the error is and how they need to fix it
```
▶ pulumi up -y -f
error: constructing secrets manager of type "passphrase": unable to find either `PULUMI_CONFIG_PASSPHRASE` nor `PULUMI_CONFIG_PASSPHRASE_FILE` when trying to access the Passphrase Secrets Manager. Please ensure one of these values are set to allow the operation to continue
```
Ideally, we would like to prompt the user for the passphrase at this
point rather than error, but the CLI could be in the middle of an
update operation as the same codepath is used for reading stackreference
values
This change addresses Python dictionary key translation issues. When the
type of `props` passed to the resource is decorated with `@input_type`,
the type's and resource's property name metadata will be used for dict
key translations instead of the resource's `translate_input_property`
and `translate_output_property` methods.
The generated provider SDKs will be updated to opt-in to this new
behavior:
- FIX: Keys in user-defined dicts will no longer be unintentionally
translated/modified.
- BREAKING: Dictionary keys in nested output classes are now
consistently snake_case. If accessing camelCase keys from such output
classes, move to accessing the values via the snake_case property
getters (or snake_case keys). Generated SDKs will log a warning
when accessing camelCase keys.
When serializing inputs:
- If a value is a dict and the associated type is an input type, the
dict's keys will be translated based on the input type's property
name metadata.
- If a value is a dict and the associated type is a dict (or Mapping),
the dict's keys will _not_ be translated.
When resolving outputs:
- If a value is a dict and the associated type is an output type, the
dict's keys will be translated based on the output type's property
name metadata.
- If a value is a dict and the associated type is a dict (or Mapping),
the dict's keys will _not_ be translated.