These changes add support for provider-side previews of create and
update operations, which allows resource providers to supply output
property values for resources that are being created or updated during a
preview.
If a plugin supports provider-side preview, its create/update methods
will be invoked during previews with the `preview` property set to true.
It is the responsibility of the provider to fill in any output
properties that are known before returning. It is a best practice for
providers to only fill in property values that are guaranteed to be
identical if the preview were instead an update (i.e. only those output
properties whose values can be conclusively determined without
actually performing the create/update operation should be populated).
Providers that support previews must accept unknown values in their
create and update methods.
If a plugin does not support provider-side preview, the inputs to a
create or update operation will be propagated to the outputs as they are
today.
Fixes#4992.
Fixes: https://github.com/pulumi/docs/issues/4340
The deprecated message sits below the examples so it is not clear
to the user that the resource / datasource is deprecated
We're not going to generate language-specific API docs for the Azure NextGen provider, only resource docs. This change makes it so the resource docs do not emit any links to nonexistent API docs.
Non-string provider inputs must be projected as JSON formatted strings. The current codegen simply calls `json.dumps` for such properties, but this does not work for the new input types, which aren't JSON serializable.
To address this, make use of the new `pulumi.runtime.to_json` utility function, which is capable of serializing raw dicts and input types as JSON.
We currently emit array types as `List[T]` for Python, but `List[T]` is invariant, which causes type checkers like mypy to produce errors when values like `["foo", "bar"]` are passed as args typed as `List[pulumi.Input[str]]`. Instead, we should move to using `Sequence[T]` which is covariant, and does not have this problem.
We actually already do this for `Dict` vs. `Mapping`, emitting map types as `Mapping[str, T]` rather than `Dict[str, T]` because `Mapping[str, T]` is covariant. This change makes us consistent for array types.
An extra constructor overload was recently added to pass undefined state from
`get` for resources that do not have any state inputs (notably Kubernetes
resources). This ended up breaking PaC's `validateResourceOfType`, which relies
on type inference in common usage to determine the resource's args type based
on the signature of the constructor.
This constructor overload isn't necessary. Instead, we can remove it and modify
how the constructor is called inside `get`. This also makes it so we're not
exposing details about `get`'s implementation in the public API.
