This change expands the definition of `resource.Output` in the Go SDK with additional information about the output, i.e. dependencies and secretness, and adds support in the core Go RPC code for (un)marshaling output values.
Output values are marshaled as special objects ala archives, assets, and resource refs and are unmarshaled as `resource.Output` values.
Subsequent PRs will add:
- A monitor feature for output values, which will initially be disabled by default but available to turn on via an envvar
- Support for (un)marshaling output values in each language SDKs
- A way for providers to indicate support for receiving output values
- E2E tests
- Turn the monitor feature on by default (w/ env var to disable) (Note: the current plan is to initially scope this to only be used when marshaling inputs to a multi-language component)
Currently whenever an issue occurs in `UnmarshalProperties` and
`MarshalProperties` the offending property is hidden and very difficult
to track down.
This commit changes the behavior. For `Assets` and `Archives` the error
message now includes the URI and for other properties it includes the
key of the `PropertyMap`.
* Introduce a test that showcases the invalid generated code
* Use shared printComment function
* Check for triple quote escaping
* Accept go
* Accept dotnet
* Accept nodejs
* Move codegen exampe into an existing schema
* Add CHANGELOG entry
* Add replaceOnChange to schema
* replaceOnChange at generate time for resources
* ReplaceOnChanges sees through optional types
* Correctly deal with map,array,object,resource type
This is responding to PR clarifications from @justinvp and @lblackstone.
* Update CHANGELOG_PENDING.md
* Detect recursively defined objects
* Display recursion warning
* Check which recursive structures fail
* Add internal logic tests for replaceOnChanges
* Add tests
This reverts commit ebb0e6aaed.
The changes in #7755 introduced a regression tracked in #7795. It is not yet clear how to retain the desired behaviour introduced in #7755 while avoiding this regression, so for now we will revert those changes, and re-open #7453 to track a deeper fix. That fix may require making changes to upstream `dill` to properly support these serialization requirements.
Fixes#7795.
- Change the schema package to report semantic errors as diagnostics
rather than Go errors
- Add a `pulumi schema check` command to the CLI for static checking of
package schemas
The semantic checker can be extended in the future to add support for
target-specific checks.
* Avoid repeatedly invoking `pip show` in Python lang host
The Python language host invokes `pip show` for each Pulumi package in a
project at startup. But `pip show` is quite slow in large projects: it
takes 2+ seconds per invocation in a project at @MaterializeInc.
`pip show` is invoked to compute the installed location of each plugin
package. But it turns out `pip list` takes a `-v` flag that can supply
this information in one shot, avoiding the need to ever invoke `pip
show`.
This patch shaves about 20s off our boot time for `pulumi up`.
(There's probably a separate bug in Pip that causes `pip show` to be so
slow, because `pip list` is an order of magnitude faster and does a lot
more work, but I didn't bother tracking that down.)
* Test and fix issue with parsing non-JSON trailer returned by pip
* Fix issues found by Go lint
* CHANGELOG entry
Co-authored-by: Nikhil Benesch <nikhil.benesch@gmail.com>
* add additional plugin install options
* update changelog
* slight re-name properties to be more idiomatic
* Apply suggestions from code review
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
* Add support for old install plugin overload, and move unshipped api changes to shipped
* add breaking note to changelog
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
* Go support for 5758 - resurrect stale PR
* Fix listStorageAccountKeys test
* Check err so linter is satisfied
* Use all the examples
* Accept codegen results
* Regenerate with PULUMI_IGNORE_AMBIENT_PLUGINS=1
* Compile and test generated code as part of the test suite
* Add a CHANGELOG entry
* Remove temp test marker
* Shorten output type name
* Simplify code
* Add issue link
* Accept more codegen changes
* Use the suggested format for linking an issue
Change `pulumi new` to use `go mod tidy` rather than `go mod download` when installing Go project dependencies, to ensure the project is fully prepared to be used by `pulumi up`, avoiding `missing go.sum entry for module` errors.
Fixes deletion order issues outlined in #7780 related to dependencies on multi language components not ensuring that all (transitive) children of the dependency are treated as dependencies.
Since the state file is not guaranteed to include all transitive dependencies explicitly specified (because dependencies on multi-langauge components will only include the dependency on the component itself, not all of it's transitive children), this PR enlightens the computation of dependencies for deletion ordering to expand the transitive dependency to include transitive children of direct dependencies.
Now there is not possible to change a name of dynamic provider resource without copying a code of the `pulumi.sdk.python.lib.pulumi.dynamic.dynamic.Resource` and changing the hard-coded name `"pulumi-python:dynamic:Resource"`. I successfully uses this proposal to make it possible.
Usage:
```python
class CustomResource(
Resource, name="my-custom-provider:CustomResource"
):
...
```
Co-authored-by: Pat Gavlin <pgavlin@gmail.com>
* Fix null exceptions when reading unknown outputs
* Fix test compilation
* Add a test reproducing the actual problem
* Revert the change in behavior that was not clearny an improvement
* Unique resource UUID
* Add a CHANGELOG entry
A few identically-typed variables got confused with the changes in #7737.
The confusion caused empty property values to be included in resources
that had any dependencies on other resources, which confused the
unmarshaling code for Go multi-language components. These changes fix
the typo and restore the original behavior, which is to omit empty
property values.
Co-authored-by: Emiliza Gutierrez <emiliza@pulumi.com>
* Work in progress, first passing tests
* Test unknown dep prop similar to Python
* Test fixes
* Fix lint
* Nit fix
* CHANGELOG
* Add ResourceInputArray and simplify the API
* Adopt urnSet
The underlying library `dill` that we use for serializing dynamic providers into Pulumi state for Python dynamic providers serializes classes differently depending on whether they are in `__main__` or in another module. We need the by-value serialization to be applied in all cases.
https://github.com/uqfoundation/dill/issues/424 is tracking adding the ability into `dill` to specify this by-value serialization explicitly, but until then, we will temporarily re-write the `__module__` of a provder class prior to serialization, so that `dill` behaves as we need for the dynamic provider use case.
Fixes#7453.
Implement Node/.NET-style dependency semantics for component resources.
Depending on a component implicitly depends on all of the component's
children. The exact set of children depends on exactly when the
component resource is observed.
Part of #7542.
Implement Node/.NET-style dependency semantics for component resources.
Depending on a component implicitly depends on all of the component's
children. The exact set of children depends on exactly when the
component resource is observed.
Part of #7542.
Do not return the inputs as the state for update previews that use an
unconfigured provider. Returning the inputs as the state allows the
language SDKs to incorrectly treat unknown properties as known (because
we can't call `Update` on an unconfigured provider, we can't know which
properties are unknown). Users can re-enable the existing behavior by
setting the `PULUMI_LEGACY_PROVIDER_PREVIEW` environment variable to a
truthy value (e.g. `1`, `true`, etc.).
Most users will be unaffected by these changes. The most common programs
that may be affected are those that combine the creation of a managed
Kubernetes cluster with the deployment of applications to that cluster. These
programs generally need to configure a k8s provider instance by constructing
a kubeconfig from the output of the managed k8s cluster. Any changes to the
cluster that cause the kubeconfig to be unknown then cause the provider to
go unconfigured at runtime. Prior to these changes, resources managed by the
k8s provider would have some known outputs in this scenario, as the engine
would treat the resource's input values as its output values. After these changes,
the resource's outputs will be treated as unknown. The most frequent affect
that this has is that applies/stack outputs that depend on the outputs of
a k8s resource managed by a provider with an unknown kubeconfig will not
run/be displayed as `output`s during previews, respectively.
We might be able to improve on this by taking advantage of schema
information and filling in unknown values for properties that do not
exist in the inputs.
Fixes#7521.
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
Co-authored-by: Luke Hoban <luke@pulumi.com>
