Commit Graph

10 Commits

Author SHA1 Message Date
Fraser Waters 48dbd6c596
Use black to format lib/test ()
Test code should be formatted and linted the same as library code. This
is the first step of that, simply including ./lib/test to the folder
that the black formatter runs on.
2024-04-23 08:29:58 +00:00
Pat Gavlin 248f78bafe [sdk/*] Add support for resource source positions
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).
2023-07-13 16:46:04 -07:00
Justin Van Patten ef41442211 [sdk/python] Add langhost test for packaged component providers
Currently fails without the fix.
2023-07-13 07:16:56 -07:00
Kyle Dixler 04a1ad401b
[sdk] deduplicate python error logs ()
This PR combines the Program failed with an unhandled exception: and traceback error messages and puts them into a single log message as well as omits the existing an unhandled error occurred message.
2022-08-11 10:38:34 -07:00
Luke Hoban eb32039013
Add `replaceOnChanges` resource option ()
Adds a new resource option to force replacement when certain properties report changes, even if the resource provider itself does not require a replacement.

Fixes .

Co-authored-by: Levi Blackstone <levi@pulumi.com>
2021-07-01 13:32:08 -06:00
Sean Gillespie ad32d9d8ac
Plumb provider version through language hosts to engine ()
* NodeJS: allow callers to override provider version

* Python: allow callers to override provider version

* NodeJS: add version for invoke

* Python: add version to invoke

* NodeJS: add tests for ReadResource

* Post-merge cleanup

* update doc comments
2019-04-23 11:02:51 -07:00
Luke Hoban 0550f71a35
Add an ignoreChanges resource option ()
Fixes .

Adds a new ignoreChanges resource option that allows specifying a list of property names whose values will be ignored during updates. The property values will be used for Create, but will be ignored for purposes of updates, and as a result also cannot trigger replacements.

This is a feature of the Pulumi engine, not of the resource providers, so no new logic is needed in providers to support this feature. Instead, the engine simply replaces the values of input properties in the goal state with old inputs for properties marked as ignoreChanges.

Currently, only top level properties may be specified in ignoreChanges. In the future, this could be extended to support paths to nested properties (including into array elements) with a JSONPath/JMESPath syntax.
2019-04-22 13:54:48 -07:00
Pat Gavlin 6e90ab0341
Add support for explicit delete-before-replace ()
These changes add a new flag to the various `ResourceOptions` types that
indicates that a resource should be deleted before it is replaced, even
if the provider does not require this behavior. The usual
delete-before-replace cascade semantics apply.

Fixes .
2019-01-31 14:27:53 -08:00
Pat Gavlin 1ecdc83a33 Implement more precise delete-before-replace semantics. ()
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.

We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.

This is perhaps clearer when described by example. Consider the
following dependency graph:

  A
__|__
B   C
|  _|_
D  E F

In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.

In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 09:46:30 -08:00
Sean Gillespie a30dcec9b1
Abnormally resolve all outputs on failed resources ()
When is resource is waiting for its dependencies to resolve, it first
informs the RPC_MANAGER that it intends to do an RPC - this is to
prevent premature termination of the program while RPCs are still in
flight or queued to execute.

However, this is a problem whenever a resource fails to create for
whatever reason. The most common ways for this to happen are for invokes
to fail, resource creation itself to fail, or throwing in an apply.
Today, this causes a deadlock, since all consumers of the failed
resources block forever while never decrementing the RPC count.

This commit addresses the issue by deliberately (abnormally) resolving
all futures that are created in the process of preparing a resource.
This solves the problem by immediately terminating all resources that
are waiting for the failed resource's outputs to resolve - they resolve
immediately, and exceptionally.

The end result is now that, instead of deadlocking, a doomed program now
terminates as expected with a single exception message.
2019-01-14 11:27:21 -08:00