Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial support for remote component construction. #5280

Merged
merged 12 commits into from
Sep 8, 2020
Merged

Conversation

pgavlin
Copy link
Member

@pgavlin pgavlin commented Sep 2, 2020

These changes add initial support for the construction of remote
components. For now, this support is limited to the NodeJS SDK;
follow-up changes will implement support for the other SDKs.

Remote components are component resources that are constructed and
managed by plugins rather than by Pulumi programs. In this sense, they
are a bit like cloud resources, and are supported by the same
distribution and plugin loading mechanisms and described by the same
schema system.

The construction of a remote component is initiated by a
RegisterResourceRequest with the new remote field set to true.
When the resource monitor receives such a request, it loads the plugin
that implements the component resource and calls the Construct
method added to the resource provider interface as part of these
changes. This method accepts the information necessary to construct the
component and its children: the component's name, type, resource
options, inputs, and input dependencies. It is responsible for
dispatching to the appropriate component factory to create the
component, then returning its URN, resolved output properties, and
output property dependencies. The dependency information is necessary to
support features such as delete-before-replace, which rely on precise
dependency information for custom resources.

These changes also add initial support for more conveniently
implementing resource providers in NodeJS. The interface used to
implement such a provider is similar to the dynamic provider interface
(and may be unified with that interface in the future).

An example of a NodeJS program constructing a remote component resource
also implemented in NodeJS can be found in
tests/construct_component/nodejs.

This is the core of #2430.

These changes add initial support for the construction of remote
components. For now, this support is limited to the NodeJS SDK;
follow-up changes will implement support for the other SDKs.

Remote components are component resources that are constructed and
managed by plugins rather than by Pulumi programs. In this sense, they
are a bit like cloud resources, and are supported by the same
distribution and plugin loading mechanisms and described by the same
schema system.

The construction of a remote component is initiated by a
`RegisterResourceRequest` with the new `remote` field set to `true`.
When the resource monitor receives such a request, it loads the plugin
that implements the component resource and calls the `Construct`
method added to the resource provider interface as part of these
changes. This method accepts the information necessary to construct the
component and its children: the component's name, type, resource
options, inputs, and input dependencies. It is responsible for
dispatching to the appropriate component factory to create the
component, then returning its URN, resolved output properties, and
output property dependencies. The dependency information is necessary to
support features such as delete-before-replace, which rely on precise
dependency information for custom resources.

These changes also add initial support for more conveniently
implementing resource providers in NodeJS. The interface used to
implement such a provider is similar to the dynamic provider interface
(and may be unified with that interface in the future).

An example of a NodeJS program constructing a remote component resource
also implemented in NodeJS can be found in
`tests/construct_component/nodejs`.

This is the core of #2430.
@pgavlin
Copy link
Member Author

pgavlin commented Sep 3, 2020

The tests that are failing in CI are also failing locally, but I'm at a loss as far as which changes would cause the failures.

Copy link
Member

@justinvp justinvp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still looking this over, but here are some initial comments.

sdk/nodejs/tsconfig.json Outdated Show resolved Hide resolved
sdk/proto/resource.proto Outdated Show resolved Hide resolved
sdk/proto/provider.proto Show resolved Hide resolved
sdk/nodejs/provider/index.ts Outdated Show resolved Hide resolved
Copy link
Member

@justinvp justinvp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

sdk/nodejs/provider/provider.ts Show resolved Hide resolved
sdk/nodejs/resource.ts Show resolved Hide resolved
sdk/nodejs/resource.ts Show resolved Hide resolved
sdk/nodejs/resource.ts Show resolved Hide resolved
sdk/nodejs/resource.ts Show resolved Hide resolved
tests/integration/integration_nodejs_test.go Show resolved Hide resolved
pkg/resource/deploy/source_eval.go Show resolved Hide resolved
pkg/resource/deploy/source_eval.go Show resolved Hide resolved
pkg/resource/deploy/source_eval.go Outdated Show resolved Hide resolved
sdk/nodejs/provider/provider.ts Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants