2018-06-26 20:14:03 +02:00
|
|
|
// Code generated by protoc-gen-go. DO NOT EDIT.
|
2017-11-17 03:21:41 +01:00
|
|
|
// source: resource.proto
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
package pulumirpc
|
2017-11-17 03:21:41 +01:00
|
|
|
|
|
|
|
import proto "github.com/golang/protobuf/proto"
|
|
|
|
import fmt "fmt"
|
|
|
|
import math "math"
|
2018-07-12 03:07:50 +02:00
|
|
|
import empty "github.com/golang/protobuf/ptypes/empty"
|
|
|
|
import _struct "github.com/golang/protobuf/ptypes/struct"
|
2017-11-17 03:21:41 +01:00
|
|
|
|
|
|
|
import (
|
|
|
|
context "golang.org/x/net/context"
|
|
|
|
grpc "google.golang.org/grpc"
|
|
|
|
)
|
|
|
|
|
|
|
|
// Reference imports to suppress errors if they are not otherwise used.
|
|
|
|
var _ = proto.Marshal
|
|
|
|
var _ = fmt.Errorf
|
|
|
|
var _ = math.Inf
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
// This is a compile-time assertion to ensure that this generated file
|
|
|
|
// is compatible with the proto package it is being compiled against.
|
|
|
|
// A compilation error at this line likely means your copy of the
|
|
|
|
// proto package needs to be updated.
|
|
|
|
const _ = proto.ProtoPackageIsVersion2 // please upgrade the proto package
|
|
|
|
|
2018-04-05 18:48:09 +02:00
|
|
|
// ReadResourceRequest contains enough information to uniquely qualify and read a resource's state.
|
|
|
|
type ReadResourceRequest struct {
|
2018-07-12 03:07:50 +02:00
|
|
|
Id string `protobuf:"bytes,1,opt,name=id" json:"id,omitempty"`
|
|
|
|
Type string `protobuf:"bytes,2,opt,name=type" json:"type,omitempty"`
|
|
|
|
Name string `protobuf:"bytes,3,opt,name=name" json:"name,omitempty"`
|
|
|
|
Parent string `protobuf:"bytes,4,opt,name=parent" json:"parent,omitempty"`
|
|
|
|
Properties *_struct.Struct `protobuf:"bytes,5,opt,name=properties" json:"properties,omitempty"`
|
2018-08-03 23:06:00 +02:00
|
|
|
Dependencies []string `protobuf:"bytes,6,rep,name=dependencies" json:"dependencies,omitempty"`
|
Implement first-class providers. (#1695)
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.
### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.
These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
or unknown properties. This is necessary because existing plugins
only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
values are known or "must replace" if any configuration value is
unknown. The justification for this behavior is given
[here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
configures the provider plugin if all config values are known. If any
config value is unknown, the underlying plugin is not configured and
the provider may only perform `Check`, `Read`, and `Invoke`, all of
which return empty results. We justify this behavior becuase it is
only possible during a preview and provides the best experience we
can manage with the existing gRPC interface.
### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.
All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.
Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.
### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
provider plugins. It must be possible to add providers from a stack's
checkpoint to this map and to register new/updated providers during
the execution of a plan in response to CRUD operations on provider
resources.
- In order to support updating existing stacks using existing Pulumi
programs that may not explicitly instantiate providers, the engine
must be able to manage the "default" providers for each package
referenced by a checkpoint or Pulumi program. The configuration for
a "default" provider is taken from the stack's configuration data.
The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").
The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.
During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.
While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.
### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
a particular provider instance to manage a `CustomResource`'s CRUD
operations.
- A new type, `InvokeOptions`, can be used to specify options that
control the behavior of a call to `pulumi.runtime.invoke`. This type
includes a `provider` field that is analogous to
`ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
|
|
|
Provider string `protobuf:"bytes,7,opt,name=provider" json:"provider,omitempty"`
|
2018-07-12 03:07:50 +02:00
|
|
|
XXX_NoUnkeyedLiteral struct{} `json:"-"`
|
|
|
|
XXX_unrecognized []byte `json:"-"`
|
|
|
|
XXX_sizecache int32 `json:"-"`
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ReadResourceRequest) Reset() { *m = ReadResourceRequest{} }
|
|
|
|
func (m *ReadResourceRequest) String() string { return proto.CompactTextString(m) }
|
|
|
|
func (*ReadResourceRequest) ProtoMessage() {}
|
|
|
|
func (*ReadResourceRequest) Descriptor() ([]byte, []int) {
|
Implement first-class providers. (#1695)
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.
### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.
These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
or unknown properties. This is necessary because existing plugins
only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
values are known or "must replace" if any configuration value is
unknown. The justification for this behavior is given
[here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
configures the provider plugin if all config values are known. If any
config value is unknown, the underlying plugin is not configured and
the provider may only perform `Check`, `Read`, and `Invoke`, all of
which return empty results. We justify this behavior becuase it is
only possible during a preview and provides the best experience we
can manage with the existing gRPC interface.
### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.
All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.
Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.
### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
provider plugins. It must be possible to add providers from a stack's
checkpoint to this map and to register new/updated providers during
the execution of a plan in response to CRUD operations on provider
resources.
- In order to support updating existing stacks using existing Pulumi
programs that may not explicitly instantiate providers, the engine
must be able to manage the "default" providers for each package
referenced by a checkpoint or Pulumi program. The configuration for
a "default" provider is taken from the stack's configuration data.
The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").
The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.
During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.
While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.
### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
a particular provider instance to manage a `CustomResource`'s CRUD
operations.
- A new type, `InvokeOptions`, can be used to specify options that
control the behavior of a call to `pulumi.runtime.invoke`. This type
includes a `provider` field that is analogous to
`ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
|
|
|
return fileDescriptor_resource_5aa1dff965971124, []int{0}
|
2018-07-12 03:07:50 +02:00
|
|
|
}
|
|
|
|
func (m *ReadResourceRequest) XXX_Unmarshal(b []byte) error {
|
|
|
|
return xxx_messageInfo_ReadResourceRequest.Unmarshal(m, b)
|
|
|
|
}
|
|
|
|
func (m *ReadResourceRequest) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
|
|
|
|
return xxx_messageInfo_ReadResourceRequest.Marshal(b, m, deterministic)
|
|
|
|
}
|
|
|
|
func (dst *ReadResourceRequest) XXX_Merge(src proto.Message) {
|
|
|
|
xxx_messageInfo_ReadResourceRequest.Merge(dst, src)
|
|
|
|
}
|
|
|
|
func (m *ReadResourceRequest) XXX_Size() int {
|
|
|
|
return xxx_messageInfo_ReadResourceRequest.Size(m)
|
|
|
|
}
|
|
|
|
func (m *ReadResourceRequest) XXX_DiscardUnknown() {
|
|
|
|
xxx_messageInfo_ReadResourceRequest.DiscardUnknown(m)
|
2018-04-05 18:48:09 +02:00
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
var xxx_messageInfo_ReadResourceRequest proto.InternalMessageInfo
|
2018-04-05 18:48:09 +02:00
|
|
|
|
|
|
|
func (m *ReadResourceRequest) GetId() string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Id
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ReadResourceRequest) GetType() string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Type
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ReadResourceRequest) GetName() string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Name
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *ReadResourceRequest) GetParent() string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Parent
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
func (m *ReadResourceRequest) GetProperties() *_struct.Struct {
|
2018-04-05 18:48:09 +02:00
|
|
|
if m != nil {
|
|
|
|
return m.Properties
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2018-08-03 23:06:00 +02:00
|
|
|
func (m *ReadResourceRequest) GetDependencies() []string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Dependencies
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
Implement first-class providers. (#1695)
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.
### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.
These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
or unknown properties. This is necessary because existing plugins
only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
values are known or "must replace" if any configuration value is
unknown. The justification for this behavior is given
[here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
configures the provider plugin if all config values are known. If any
config value is unknown, the underlying plugin is not configured and
the provider may only perform `Check`, `Read`, and `Invoke`, all of
which return empty results. We justify this behavior becuase it is
only possible during a preview and provides the best experience we
can manage with the existing gRPC interface.
### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.
All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.
Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.
### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
provider plugins. It must be possible to add providers from a stack's
checkpoint to this map and to register new/updated providers during
the execution of a plan in response to CRUD operations on provider
resources.
- In order to support updating existing stacks using existing Pulumi
programs that may not explicitly instantiate providers, the engine
must be able to manage the "default" providers for each package
referenced by a checkpoint or Pulumi program. The configuration for
a "default" provider is taken from the stack's configuration data.
The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").
The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.
During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.
While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.
### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
a particular provider instance to manage a `CustomResource`'s CRUD
operations.
- A new type, `InvokeOptions`, can be used to specify options that
control the behavior of a call to `pulumi.runtime.invoke`. This type
includes a `provider` field that is analogous to
`ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
|
|
|
func (m *ReadResourceRequest) GetProvider() string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Provider
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
2018-04-05 18:48:09 +02:00
|
|
|
// ReadResourceResponse contains the result of reading a resource's state.
|
|
|
|
type ReadResourceResponse struct {
|
2018-07-12 03:07:50 +02:00
|
|
|
Urn string `protobuf:"bytes,1,opt,name=urn" json:"urn,omitempty"`
|
|
|
|
Properties *_struct.Struct `protobuf:"bytes,2,opt,name=properties" json:"properties,omitempty"`
|
|
|
|
XXX_NoUnkeyedLiteral struct{} `json:"-"`
|
|
|
|
XXX_unrecognized []byte `json:"-"`
|
|
|
|
XXX_sizecache int32 `json:"-"`
|
2018-04-05 18:48:09 +02:00
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
func (m *ReadResourceResponse) Reset() { *m = ReadResourceResponse{} }
|
|
|
|
func (m *ReadResourceResponse) String() string { return proto.CompactTextString(m) }
|
|
|
|
func (*ReadResourceResponse) ProtoMessage() {}
|
|
|
|
func (*ReadResourceResponse) Descriptor() ([]byte, []int) {
|
Implement first-class providers. (#1695)
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.
### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.
These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
or unknown properties. This is necessary because existing plugins
only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
values are known or "must replace" if any configuration value is
unknown. The justification for this behavior is given
[here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
configures the provider plugin if all config values are known. If any
config value is unknown, the underlying plugin is not configured and
the provider may only perform `Check`, `Read`, and `Invoke`, all of
which return empty results. We justify this behavior becuase it is
only possible during a preview and provides the best experience we
can manage with the existing gRPC interface.
### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.
All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.
Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.
### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
provider plugins. It must be possible to add providers from a stack's
checkpoint to this map and to register new/updated providers during
the execution of a plan in response to CRUD operations on provider
resources.
- In order to support updating existing stacks using existing Pulumi
programs that may not explicitly instantiate providers, the engine
must be able to manage the "default" providers for each package
referenced by a checkpoint or Pulumi program. The configuration for
a "default" provider is taken from the stack's configuration data.
The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").
The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.
During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.
While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.
### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
a particular provider instance to manage a `CustomResource`'s CRUD
operations.
- A new type, `InvokeOptions`, can be used to specify options that
control the behavior of a call to `pulumi.runtime.invoke`. This type
includes a `provider` field that is analogous to
`ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
|
|
|
return fileDescriptor_resource_5aa1dff965971124, []int{1}
|
2018-07-12 03:07:50 +02:00
|
|
|
}
|
|
|
|
func (m *ReadResourceResponse) XXX_Unmarshal(b []byte) error {
|
|
|
|
return xxx_messageInfo_ReadResourceResponse.Unmarshal(m, b)
|
|
|
|
}
|
|
|
|
func (m *ReadResourceResponse) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
|
|
|
|
return xxx_messageInfo_ReadResourceResponse.Marshal(b, m, deterministic)
|
|
|
|
}
|
|
|
|
func (dst *ReadResourceResponse) XXX_Merge(src proto.Message) {
|
|
|
|
xxx_messageInfo_ReadResourceResponse.Merge(dst, src)
|
|
|
|
}
|
|
|
|
func (m *ReadResourceResponse) XXX_Size() int {
|
|
|
|
return xxx_messageInfo_ReadResourceResponse.Size(m)
|
|
|
|
}
|
|
|
|
func (m *ReadResourceResponse) XXX_DiscardUnknown() {
|
|
|
|
xxx_messageInfo_ReadResourceResponse.DiscardUnknown(m)
|
|
|
|
}
|
|
|
|
|
|
|
|
var xxx_messageInfo_ReadResourceResponse proto.InternalMessageInfo
|
2018-04-05 18:48:09 +02:00
|
|
|
|
|
|
|
func (m *ReadResourceResponse) GetUrn() string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Urn
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
func (m *ReadResourceResponse) GetProperties() *_struct.Struct {
|
2018-04-05 18:48:09 +02:00
|
|
|
if m != nil {
|
|
|
|
return m.Properties
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
// RegisterResourceRequest contains information about a resource object that was newly allocated.
|
|
|
|
type RegisterResourceRequest struct {
|
2018-07-12 03:07:50 +02:00
|
|
|
Type string `protobuf:"bytes,1,opt,name=type" json:"type,omitempty"`
|
|
|
|
Name string `protobuf:"bytes,2,opt,name=name" json:"name,omitempty"`
|
|
|
|
Parent string `protobuf:"bytes,3,opt,name=parent" json:"parent,omitempty"`
|
|
|
|
Custom bool `protobuf:"varint,4,opt,name=custom" json:"custom,omitempty"`
|
|
|
|
Object *_struct.Struct `protobuf:"bytes,5,opt,name=object" json:"object,omitempty"`
|
|
|
|
Protect bool `protobuf:"varint,6,opt,name=protect" json:"protect,omitempty"`
|
|
|
|
Dependencies []string `protobuf:"bytes,7,rep,name=dependencies" json:"dependencies,omitempty"`
|
Implement first-class providers. (#1695)
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.
### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.
These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
or unknown properties. This is necessary because existing plugins
only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
values are known or "must replace" if any configuration value is
unknown. The justification for this behavior is given
[here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
configures the provider plugin if all config values are known. If any
config value is unknown, the underlying plugin is not configured and
the provider may only perform `Check`, `Read`, and `Invoke`, all of
which return empty results. We justify this behavior becuase it is
only possible during a preview and provides the best experience we
can manage with the existing gRPC interface.
### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.
All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.
Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.
### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
provider plugins. It must be possible to add providers from a stack's
checkpoint to this map and to register new/updated providers during
the execution of a plan in response to CRUD operations on provider
resources.
- In order to support updating existing stacks using existing Pulumi
programs that may not explicitly instantiate providers, the engine
must be able to manage the "default" providers for each package
referenced by a checkpoint or Pulumi program. The configuration for
a "default" provider is taken from the stack's configuration data.
The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").
The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.
During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.
While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.
### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
a particular provider instance to manage a `CustomResource`'s CRUD
operations.
- A new type, `InvokeOptions`, can be used to specify options that
control the behavior of a call to `pulumi.runtime.invoke`. This type
includes a `provider` field that is analogous to
`ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
|
|
|
Provider string `protobuf:"bytes,8,opt,name=provider" json:"provider,omitempty"`
|
2018-07-12 03:07:50 +02:00
|
|
|
XXX_NoUnkeyedLiteral struct{} `json:"-"`
|
|
|
|
XXX_unrecognized []byte `json:"-"`
|
|
|
|
XXX_sizecache int32 `json:"-"`
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
func (m *RegisterResourceRequest) Reset() { *m = RegisterResourceRequest{} }
|
|
|
|
func (m *RegisterResourceRequest) String() string { return proto.CompactTextString(m) }
|
|
|
|
func (*RegisterResourceRequest) ProtoMessage() {}
|
|
|
|
func (*RegisterResourceRequest) Descriptor() ([]byte, []int) {
|
Implement first-class providers. (#1695)
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.
### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.
These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
or unknown properties. This is necessary because existing plugins
only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
values are known or "must replace" if any configuration value is
unknown. The justification for this behavior is given
[here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
configures the provider plugin if all config values are known. If any
config value is unknown, the underlying plugin is not configured and
the provider may only perform `Check`, `Read`, and `Invoke`, all of
which return empty results. We justify this behavior becuase it is
only possible during a preview and provides the best experience we
can manage with the existing gRPC interface.
### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.
All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.
Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.
### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
provider plugins. It must be possible to add providers from a stack's
checkpoint to this map and to register new/updated providers during
the execution of a plan in response to CRUD operations on provider
resources.
- In order to support updating existing stacks using existing Pulumi
programs that may not explicitly instantiate providers, the engine
must be able to manage the "default" providers for each package
referenced by a checkpoint or Pulumi program. The configuration for
a "default" provider is taken from the stack's configuration data.
The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").
The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.
During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.
While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.
### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
a particular provider instance to manage a `CustomResource`'s CRUD
operations.
- A new type, `InvokeOptions`, can be used to specify options that
control the behavior of a call to `pulumi.runtime.invoke`. This type
includes a `provider` field that is analogous to
`ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
|
|
|
return fileDescriptor_resource_5aa1dff965971124, []int{2}
|
2018-07-12 03:07:50 +02:00
|
|
|
}
|
|
|
|
func (m *RegisterResourceRequest) XXX_Unmarshal(b []byte) error {
|
|
|
|
return xxx_messageInfo_RegisterResourceRequest.Unmarshal(m, b)
|
|
|
|
}
|
|
|
|
func (m *RegisterResourceRequest) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
|
|
|
|
return xxx_messageInfo_RegisterResourceRequest.Marshal(b, m, deterministic)
|
|
|
|
}
|
|
|
|
func (dst *RegisterResourceRequest) XXX_Merge(src proto.Message) {
|
|
|
|
xxx_messageInfo_RegisterResourceRequest.Merge(dst, src)
|
|
|
|
}
|
|
|
|
func (m *RegisterResourceRequest) XXX_Size() int {
|
|
|
|
return xxx_messageInfo_RegisterResourceRequest.Size(m)
|
|
|
|
}
|
|
|
|
func (m *RegisterResourceRequest) XXX_DiscardUnknown() {
|
|
|
|
xxx_messageInfo_RegisterResourceRequest.DiscardUnknown(m)
|
|
|
|
}
|
|
|
|
|
|
|
|
var xxx_messageInfo_RegisterResourceRequest proto.InternalMessageInfo
|
2017-11-17 03:21:41 +01:00
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func (m *RegisterResourceRequest) GetType() string {
|
2017-11-17 03:21:41 +01:00
|
|
|
if m != nil {
|
|
|
|
return m.Type
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func (m *RegisterResourceRequest) GetName() string {
|
2017-11-17 03:21:41 +01:00
|
|
|
if m != nil {
|
|
|
|
return m.Name
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func (m *RegisterResourceRequest) GetParent() string {
|
2017-11-17 03:21:41 +01:00
|
|
|
if m != nil {
|
|
|
|
return m.Parent
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func (m *RegisterResourceRequest) GetCustom() bool {
|
2017-11-17 03:21:41 +01:00
|
|
|
if m != nil {
|
|
|
|
return m.Custom
|
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
func (m *RegisterResourceRequest) GetObject() *_struct.Struct {
|
2017-11-17 03:21:41 +01:00
|
|
|
if m != nil {
|
|
|
|
return m.Object
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
Implement resource protection (#751)
This change implements resource protection, as per pulumi/pulumi#689.
The overall idea is that a resource can be marked as "protect: true",
which will prevent deletion of that resource for any reason whatsoever
(straight deletion, replacement, etc). This is expressed in the
program. To "unprotect" a resource, one must perform an update setting
"protect: false", and then afterwards, they can delete the resource.
For example:
let res = new MyResource("precious", { .. }, { protect: true });
Afterwards, the resource will display in the CLI with a lock icon, and
any attempts to remove it will fail in the usual ways (in planning or,
worst case, during an actual update).
This was done by adding a new ResourceOptions bag parameter to the
base Resource types. This is unfortunately a breaking change, but now
is the right time to take this one. We had been adding new settings
one by one -- like parent and dependsOn -- and this new approach will
set us up to add any number of additional settings down the road,
without needing to worry about breaking anything ever again.
This is related to protected stacks, as described in
pulumi/pulumi-service#399. Most likely this will serve as a foundational
building block that enables the coarser grained policy management.
2017-12-20 23:31:07 +01:00
|
|
|
func (m *RegisterResourceRequest) GetProtect() bool {
|
|
|
|
if m != nil {
|
|
|
|
return m.Protect
|
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
2018-02-22 00:11:21 +01:00
|
|
|
func (m *RegisterResourceRequest) GetDependencies() []string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Dependencies
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
Implement first-class providers. (#1695)
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.
### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.
These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
or unknown properties. This is necessary because existing plugins
only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
values are known or "must replace" if any configuration value is
unknown. The justification for this behavior is given
[here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
configures the provider plugin if all config values are known. If any
config value is unknown, the underlying plugin is not configured and
the provider may only perform `Check`, `Read`, and `Invoke`, all of
which return empty results. We justify this behavior becuase it is
only possible during a preview and provides the best experience we
can manage with the existing gRPC interface.
### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.
All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.
Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.
### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
provider plugins. It must be possible to add providers from a stack's
checkpoint to this map and to register new/updated providers during
the execution of a plan in response to CRUD operations on provider
resources.
- In order to support updating existing stacks using existing Pulumi
programs that may not explicitly instantiate providers, the engine
must be able to manage the "default" providers for each package
referenced by a checkpoint or Pulumi program. The configuration for
a "default" provider is taken from the stack's configuration data.
The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").
The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.
During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.
While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.
### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
a particular provider instance to manage a `CustomResource`'s CRUD
operations.
- A new type, `InvokeOptions`, can be used to specify options that
control the behavior of a call to `pulumi.runtime.invoke`. This type
includes a `provider` field that is analogous to
`ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
|
|
|
func (m *RegisterResourceRequest) GetProvider() string {
|
|
|
|
if m != nil {
|
|
|
|
return m.Provider
|
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
// RegisterResourceResponse is returned by the engine after a resource has finished being initialized. It includes the
|
|
|
|
// auto-assigned URN, the provider-assigned ID, and any other properties initialized by the engine.
|
|
|
|
type RegisterResourceResponse struct {
|
2018-07-12 03:07:50 +02:00
|
|
|
Urn string `protobuf:"bytes,1,opt,name=urn" json:"urn,omitempty"`
|
|
|
|
Id string `protobuf:"bytes,2,opt,name=id" json:"id,omitempty"`
|
|
|
|
Object *_struct.Struct `protobuf:"bytes,3,opt,name=object" json:"object,omitempty"`
|
|
|
|
Stable bool `protobuf:"varint,4,opt,name=stable" json:"stable,omitempty"`
|
|
|
|
Stables []string `protobuf:"bytes,5,rep,name=stables" json:"stables,omitempty"`
|
|
|
|
XXX_NoUnkeyedLiteral struct{} `json:"-"`
|
|
|
|
XXX_unrecognized []byte `json:"-"`
|
|
|
|
XXX_sizecache int32 `json:"-"`
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *RegisterResourceResponse) Reset() { *m = RegisterResourceResponse{} }
|
|
|
|
func (m *RegisterResourceResponse) String() string { return proto.CompactTextString(m) }
|
|
|
|
func (*RegisterResourceResponse) ProtoMessage() {}
|
|
|
|
func (*RegisterResourceResponse) Descriptor() ([]byte, []int) {
|
Implement first-class providers. (#1695)
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.
### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.
These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
or unknown properties. This is necessary because existing plugins
only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
values are known or "must replace" if any configuration value is
unknown. The justification for this behavior is given
[here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
configures the provider plugin if all config values are known. If any
config value is unknown, the underlying plugin is not configured and
the provider may only perform `Check`, `Read`, and `Invoke`, all of
which return empty results. We justify this behavior becuase it is
only possible during a preview and provides the best experience we
can manage with the existing gRPC interface.
### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.
All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.
Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.
### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
provider plugins. It must be possible to add providers from a stack's
checkpoint to this map and to register new/updated providers during
the execution of a plan in response to CRUD operations on provider
resources.
- In order to support updating existing stacks using existing Pulumi
programs that may not explicitly instantiate providers, the engine
must be able to manage the "default" providers for each package
referenced by a checkpoint or Pulumi program. The configuration for
a "default" provider is taken from the stack's configuration data.
The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").
The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.
During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.
While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.
### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
a particular provider instance to manage a `CustomResource`'s CRUD
operations.
- A new type, `InvokeOptions`, can be used to specify options that
control the behavior of a call to `pulumi.runtime.invoke`. This type
includes a `provider` field that is analogous to
`ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
|
|
|
return fileDescriptor_resource_5aa1dff965971124, []int{3}
|
2018-07-12 03:07:50 +02:00
|
|
|
}
|
|
|
|
func (m *RegisterResourceResponse) XXX_Unmarshal(b []byte) error {
|
|
|
|
return xxx_messageInfo_RegisterResourceResponse.Unmarshal(m, b)
|
|
|
|
}
|
|
|
|
func (m *RegisterResourceResponse) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
|
|
|
|
return xxx_messageInfo_RegisterResourceResponse.Marshal(b, m, deterministic)
|
|
|
|
}
|
|
|
|
func (dst *RegisterResourceResponse) XXX_Merge(src proto.Message) {
|
|
|
|
xxx_messageInfo_RegisterResourceResponse.Merge(dst, src)
|
|
|
|
}
|
|
|
|
func (m *RegisterResourceResponse) XXX_Size() int {
|
|
|
|
return xxx_messageInfo_RegisterResourceResponse.Size(m)
|
|
|
|
}
|
|
|
|
func (m *RegisterResourceResponse) XXX_DiscardUnknown() {
|
|
|
|
xxx_messageInfo_RegisterResourceResponse.DiscardUnknown(m)
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
var xxx_messageInfo_RegisterResourceResponse proto.InternalMessageInfo
|
2017-11-17 03:21:41 +01:00
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func (m *RegisterResourceResponse) GetUrn() string {
|
2017-11-17 03:21:41 +01:00
|
|
|
if m != nil {
|
2017-11-21 02:38:09 +01:00
|
|
|
return m.Urn
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func (m *RegisterResourceResponse) GetId() string {
|
2017-11-17 03:21:41 +01:00
|
|
|
if m != nil {
|
2017-11-29 20:27:32 +01:00
|
|
|
return m.Id
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
return ""
|
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
func (m *RegisterResourceResponse) GetObject() *_struct.Struct {
|
2017-11-21 02:38:09 +01:00
|
|
|
if m != nil {
|
2017-11-29 20:27:32 +01:00
|
|
|
return m.Object
|
2017-11-21 02:38:09 +01:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func (m *RegisterResourceResponse) GetStable() bool {
|
2017-11-21 02:38:09 +01:00
|
|
|
if m != nil {
|
2017-11-29 20:27:32 +01:00
|
|
|
return m.Stable
|
2017-11-21 02:38:09 +01:00
|
|
|
}
|
2017-11-29 20:27:32 +01:00
|
|
|
return false
|
2017-11-21 02:38:09 +01:00
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func (m *RegisterResourceResponse) GetStables() []string {
|
2017-11-17 03:21:41 +01:00
|
|
|
if m != nil {
|
2017-11-29 20:27:32 +01:00
|
|
|
return m.Stables
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
// RegisterResourceOutputsRequest adds extra resource outputs created by the program after registration has occurred.
|
|
|
|
type RegisterResourceOutputsRequest struct {
|
2018-07-12 03:07:50 +02:00
|
|
|
Urn string `protobuf:"bytes,1,opt,name=urn" json:"urn,omitempty"`
|
|
|
|
Outputs *_struct.Struct `protobuf:"bytes,2,opt,name=outputs" json:"outputs,omitempty"`
|
|
|
|
XXX_NoUnkeyedLiteral struct{} `json:"-"`
|
|
|
|
XXX_unrecognized []byte `json:"-"`
|
|
|
|
XXX_sizecache int32 `json:"-"`
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m *RegisterResourceOutputsRequest) Reset() { *m = RegisterResourceOutputsRequest{} }
|
|
|
|
func (m *RegisterResourceOutputsRequest) String() string { return proto.CompactTextString(m) }
|
|
|
|
func (*RegisterResourceOutputsRequest) ProtoMessage() {}
|
|
|
|
func (*RegisterResourceOutputsRequest) Descriptor() ([]byte, []int) {
|
Implement first-class providers. (#1695)
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.
### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.
These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
or unknown properties. This is necessary because existing plugins
only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
values are known or "must replace" if any configuration value is
unknown. The justification for this behavior is given
[here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
configures the provider plugin if all config values are known. If any
config value is unknown, the underlying plugin is not configured and
the provider may only perform `Check`, `Read`, and `Invoke`, all of
which return empty results. We justify this behavior becuase it is
only possible during a preview and provides the best experience we
can manage with the existing gRPC interface.
### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.
All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.
Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.
### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
provider plugins. It must be possible to add providers from a stack's
checkpoint to this map and to register new/updated providers during
the execution of a plan in response to CRUD operations on provider
resources.
- In order to support updating existing stacks using existing Pulumi
programs that may not explicitly instantiate providers, the engine
must be able to manage the "default" providers for each package
referenced by a checkpoint or Pulumi program. The configuration for
a "default" provider is taken from the stack's configuration data.
The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").
The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.
During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.
While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.
### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
a particular provider instance to manage a `CustomResource`'s CRUD
operations.
- A new type, `InvokeOptions`, can be used to specify options that
control the behavior of a call to `pulumi.runtime.invoke`. This type
includes a `provider` field that is analogous to
`ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
|
|
|
return fileDescriptor_resource_5aa1dff965971124, []int{4}
|
2018-07-12 03:07:50 +02:00
|
|
|
}
|
|
|
|
func (m *RegisterResourceOutputsRequest) XXX_Unmarshal(b []byte) error {
|
|
|
|
return xxx_messageInfo_RegisterResourceOutputsRequest.Unmarshal(m, b)
|
|
|
|
}
|
|
|
|
func (m *RegisterResourceOutputsRequest) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
|
|
|
|
return xxx_messageInfo_RegisterResourceOutputsRequest.Marshal(b, m, deterministic)
|
|
|
|
}
|
|
|
|
func (dst *RegisterResourceOutputsRequest) XXX_Merge(src proto.Message) {
|
|
|
|
xxx_messageInfo_RegisterResourceOutputsRequest.Merge(dst, src)
|
|
|
|
}
|
|
|
|
func (m *RegisterResourceOutputsRequest) XXX_Size() int {
|
|
|
|
return xxx_messageInfo_RegisterResourceOutputsRequest.Size(m)
|
|
|
|
}
|
|
|
|
func (m *RegisterResourceOutputsRequest) XXX_DiscardUnknown() {
|
|
|
|
xxx_messageInfo_RegisterResourceOutputsRequest.DiscardUnknown(m)
|
2017-11-29 20:27:32 +01:00
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
var xxx_messageInfo_RegisterResourceOutputsRequest proto.InternalMessageInfo
|
2017-11-29 20:27:32 +01:00
|
|
|
|
|
|
|
func (m *RegisterResourceOutputsRequest) GetUrn() string {
|
2017-11-17 03:21:41 +01:00
|
|
|
if m != nil {
|
2017-11-29 20:27:32 +01:00
|
|
|
return m.Urn
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
2017-11-29 20:27:32 +01:00
|
|
|
return ""
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
func (m *RegisterResourceOutputsRequest) GetOutputs() *_struct.Struct {
|
2017-11-17 03:21:41 +01:00
|
|
|
if m != nil {
|
2017-11-29 20:27:32 +01:00
|
|
|
return m.Outputs
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func init() {
|
2018-04-05 18:48:09 +02:00
|
|
|
proto.RegisterType((*ReadResourceRequest)(nil), "pulumirpc.ReadResourceRequest")
|
|
|
|
proto.RegisterType((*ReadResourceResponse)(nil), "pulumirpc.ReadResourceResponse")
|
2017-11-29 20:27:32 +01:00
|
|
|
proto.RegisterType((*RegisterResourceRequest)(nil), "pulumirpc.RegisterResourceRequest")
|
|
|
|
proto.RegisterType((*RegisterResourceResponse)(nil), "pulumirpc.RegisterResourceResponse")
|
|
|
|
proto.RegisterType((*RegisterResourceOutputsRequest)(nil), "pulumirpc.RegisterResourceOutputsRequest")
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// Reference imports to suppress errors if they are not otherwise used.
|
|
|
|
var _ context.Context
|
|
|
|
var _ grpc.ClientConn
|
|
|
|
|
|
|
|
// This is a compile-time assertion to ensure that this generated file
|
|
|
|
// is compatible with the grpc package it is being compiled against.
|
|
|
|
const _ = grpc.SupportPackageIsVersion4
|
|
|
|
|
2018-06-30 01:14:49 +02:00
|
|
|
// Client API for ResourceMonitor service
|
|
|
|
|
2017-11-17 03:21:41 +01:00
|
|
|
type ResourceMonitorClient interface {
|
|
|
|
Invoke(ctx context.Context, in *InvokeRequest, opts ...grpc.CallOption) (*InvokeResponse, error)
|
2018-04-05 18:48:09 +02:00
|
|
|
ReadResource(ctx context.Context, in *ReadResourceRequest, opts ...grpc.CallOption) (*ReadResourceResponse, error)
|
2017-11-29 20:27:32 +01:00
|
|
|
RegisterResource(ctx context.Context, in *RegisterResourceRequest, opts ...grpc.CallOption) (*RegisterResourceResponse, error)
|
2018-07-12 03:07:50 +02:00
|
|
|
RegisterResourceOutputs(ctx context.Context, in *RegisterResourceOutputsRequest, opts ...grpc.CallOption) (*empty.Empty, error)
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
type resourceMonitorClient struct {
|
|
|
|
cc *grpc.ClientConn
|
|
|
|
}
|
|
|
|
|
|
|
|
func NewResourceMonitorClient(cc *grpc.ClientConn) ResourceMonitorClient {
|
|
|
|
return &resourceMonitorClient{cc}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (c *resourceMonitorClient) Invoke(ctx context.Context, in *InvokeRequest, opts ...grpc.CallOption) (*InvokeResponse, error) {
|
|
|
|
out := new(InvokeResponse)
|
2018-06-30 01:14:49 +02:00
|
|
|
err := grpc.Invoke(ctx, "/pulumirpc.ResourceMonitor/Invoke", in, out, c.cc, opts...)
|
2017-11-17 03:21:41 +01:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return out, nil
|
|
|
|
}
|
|
|
|
|
2018-04-05 18:48:09 +02:00
|
|
|
func (c *resourceMonitorClient) ReadResource(ctx context.Context, in *ReadResourceRequest, opts ...grpc.CallOption) (*ReadResourceResponse, error) {
|
|
|
|
out := new(ReadResourceResponse)
|
2018-06-30 01:14:49 +02:00
|
|
|
err := grpc.Invoke(ctx, "/pulumirpc.ResourceMonitor/ReadResource", in, out, c.cc, opts...)
|
2018-04-05 18:48:09 +02:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return out, nil
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func (c *resourceMonitorClient) RegisterResource(ctx context.Context, in *RegisterResourceRequest, opts ...grpc.CallOption) (*RegisterResourceResponse, error) {
|
|
|
|
out := new(RegisterResourceResponse)
|
2018-06-30 01:14:49 +02:00
|
|
|
err := grpc.Invoke(ctx, "/pulumirpc.ResourceMonitor/RegisterResource", in, out, c.cc, opts...)
|
2017-11-21 02:38:09 +01:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return out, nil
|
|
|
|
}
|
|
|
|
|
2018-07-12 03:07:50 +02:00
|
|
|
func (c *resourceMonitorClient) RegisterResourceOutputs(ctx context.Context, in *RegisterResourceOutputsRequest, opts ...grpc.CallOption) (*empty.Empty, error) {
|
|
|
|
out := new(empty.Empty)
|
2018-06-30 01:14:49 +02:00
|
|
|
err := grpc.Invoke(ctx, "/pulumirpc.ResourceMonitor/RegisterResourceOutputs", in, out, c.cc, opts...)
|
2017-11-17 03:21:41 +01:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return out, nil
|
|
|
|
}
|
|
|
|
|
2018-06-30 01:14:49 +02:00
|
|
|
// Server API for ResourceMonitor service
|
|
|
|
|
2017-11-17 03:21:41 +01:00
|
|
|
type ResourceMonitorServer interface {
|
|
|
|
Invoke(context.Context, *InvokeRequest) (*InvokeResponse, error)
|
2018-04-05 18:48:09 +02:00
|
|
|
ReadResource(context.Context, *ReadResourceRequest) (*ReadResourceResponse, error)
|
2017-11-29 20:27:32 +01:00
|
|
|
RegisterResource(context.Context, *RegisterResourceRequest) (*RegisterResourceResponse, error)
|
2018-07-12 03:07:50 +02:00
|
|
|
RegisterResourceOutputs(context.Context, *RegisterResourceOutputsRequest) (*empty.Empty, error)
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
func RegisterResourceMonitorServer(s *grpc.Server, srv ResourceMonitorServer) {
|
|
|
|
s.RegisterService(&_ResourceMonitor_serviceDesc, srv)
|
|
|
|
}
|
|
|
|
|
|
|
|
func _ResourceMonitor_Invoke_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
|
|
|
|
in := new(InvokeRequest)
|
|
|
|
if err := dec(in); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if interceptor == nil {
|
|
|
|
return srv.(ResourceMonitorServer).Invoke(ctx, in)
|
|
|
|
}
|
|
|
|
info := &grpc.UnaryServerInfo{
|
|
|
|
Server: srv,
|
|
|
|
FullMethod: "/pulumirpc.ResourceMonitor/Invoke",
|
|
|
|
}
|
|
|
|
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
|
|
|
|
return srv.(ResourceMonitorServer).Invoke(ctx, req.(*InvokeRequest))
|
|
|
|
}
|
|
|
|
return interceptor(ctx, in, info, handler)
|
|
|
|
}
|
|
|
|
|
2018-04-05 18:48:09 +02:00
|
|
|
func _ResourceMonitor_ReadResource_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
|
|
|
|
in := new(ReadResourceRequest)
|
|
|
|
if err := dec(in); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if interceptor == nil {
|
|
|
|
return srv.(ResourceMonitorServer).ReadResource(ctx, in)
|
|
|
|
}
|
|
|
|
info := &grpc.UnaryServerInfo{
|
|
|
|
Server: srv,
|
|
|
|
FullMethod: "/pulumirpc.ResourceMonitor/ReadResource",
|
|
|
|
}
|
|
|
|
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
|
|
|
|
return srv.(ResourceMonitorServer).ReadResource(ctx, req.(*ReadResourceRequest))
|
|
|
|
}
|
|
|
|
return interceptor(ctx, in, info, handler)
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func _ResourceMonitor_RegisterResource_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
|
|
|
|
in := new(RegisterResourceRequest)
|
2017-11-17 03:21:41 +01:00
|
|
|
if err := dec(in); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if interceptor == nil {
|
2017-11-29 20:27:32 +01:00
|
|
|
return srv.(ResourceMonitorServer).RegisterResource(ctx, in)
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
info := &grpc.UnaryServerInfo{
|
|
|
|
Server: srv,
|
2017-11-29 20:27:32 +01:00
|
|
|
FullMethod: "/pulumirpc.ResourceMonitor/RegisterResource",
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
|
2017-11-29 20:27:32 +01:00
|
|
|
return srv.(ResourceMonitorServer).RegisterResource(ctx, req.(*RegisterResourceRequest))
|
2017-11-21 02:38:09 +01:00
|
|
|
}
|
|
|
|
return interceptor(ctx, in, info, handler)
|
|
|
|
}
|
|
|
|
|
2017-11-29 20:27:32 +01:00
|
|
|
func _ResourceMonitor_RegisterResourceOutputs_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error, interceptor grpc.UnaryServerInterceptor) (interface{}, error) {
|
|
|
|
in := new(RegisterResourceOutputsRequest)
|
2017-11-21 02:38:09 +01:00
|
|
|
if err := dec(in); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
if interceptor == nil {
|
2017-11-29 20:27:32 +01:00
|
|
|
return srv.(ResourceMonitorServer).RegisterResourceOutputs(ctx, in)
|
2017-11-21 02:38:09 +01:00
|
|
|
}
|
|
|
|
info := &grpc.UnaryServerInfo{
|
|
|
|
Server: srv,
|
2017-11-29 20:27:32 +01:00
|
|
|
FullMethod: "/pulumirpc.ResourceMonitor/RegisterResourceOutputs",
|
2017-11-21 02:38:09 +01:00
|
|
|
}
|
|
|
|
handler := func(ctx context.Context, req interface{}) (interface{}, error) {
|
2017-11-29 20:27:32 +01:00
|
|
|
return srv.(ResourceMonitorServer).RegisterResourceOutputs(ctx, req.(*RegisterResourceOutputsRequest))
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|
|
|
|
return interceptor(ctx, in, info, handler)
|
|
|
|
}
|
|
|
|
|
|
|
|
var _ResourceMonitor_serviceDesc = grpc.ServiceDesc{
|
|
|
|
ServiceName: "pulumirpc.ResourceMonitor",
|
|
|
|
HandlerType: (*ResourceMonitorServer)(nil),
|
|
|
|
Methods: []grpc.MethodDesc{
|
|
|
|
{
|
|
|
|
MethodName: "Invoke",
|
|
|
|
Handler: _ResourceMonitor_Invoke_Handler,
|
|
|
|
},
|
2018-04-05 18:48:09 +02:00
|
|
|
{
|
|
|
|
MethodName: "ReadResource",
|
|
|
|
Handler: _ResourceMonitor_ReadResource_Handler,
|
|
|
|
},
|
2017-11-17 03:21:41 +01:00
|
|
|
{
|
2017-11-29 20:27:32 +01:00
|
|
|
MethodName: "RegisterResource",
|
|
|
|
Handler: _ResourceMonitor_RegisterResource_Handler,
|
2017-11-21 02:38:09 +01:00
|
|
|
},
|
|
|
|
{
|
2017-11-29 20:27:32 +01:00
|
|
|
MethodName: "RegisterResourceOutputs",
|
|
|
|
Handler: _ResourceMonitor_RegisterResourceOutputs_Handler,
|
2017-11-17 03:21:41 +01:00
|
|
|
},
|
|
|
|
},
|
|
|
|
Streams: []grpc.StreamDesc{},
|
|
|
|
Metadata: "resource.proto",
|
|
|
|
}
|
|
|
|
|
Implement first-class providers. (#1695)
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.
### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.
These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
or unknown properties. This is necessary because existing plugins
only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
values are known or "must replace" if any configuration value is
unknown. The justification for this behavior is given
[here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
configures the provider plugin if all config values are known. If any
config value is unknown, the underlying plugin is not configured and
the provider may only perform `Check`, `Read`, and `Invoke`, all of
which return empty results. We justify this behavior becuase it is
only possible during a preview and provides the best experience we
can manage with the existing gRPC interface.
### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.
All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.
Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.
### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
provider plugins. It must be possible to add providers from a stack's
checkpoint to this map and to register new/updated providers during
the execution of a plan in response to CRUD operations on provider
resources.
- In order to support updating existing stacks using existing Pulumi
programs that may not explicitly instantiate providers, the engine
must be able to manage the "default" providers for each package
referenced by a checkpoint or Pulumi program. The configuration for
a "default" provider is taken from the stack's configuration data.
The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").
The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.
During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.
While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.
### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
a particular provider instance to manage a `CustomResource`'s CRUD
operations.
- A new type, `InvokeOptions`, can be used to specify options that
control the behavior of a call to `pulumi.runtime.invoke`. This type
includes a `provider` field that is analogous to
`ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
|
|
|
func init() { proto.RegisterFile("resource.proto", fileDescriptor_resource_5aa1dff965971124) }
|
|
|
|
|
|
|
|
var fileDescriptor_resource_5aa1dff965971124 = []byte{
|
|
|
|
// 491 bytes of a gzipped FileDescriptorProto
|
|
|
|
0x1f, 0x8b, 0x08, 0x00, 0x00, 0x09, 0x6e, 0x88, 0x02, 0xff, 0x8c, 0x94, 0xcd, 0x6e, 0xd3, 0x40,
|
|
|
|
0x10, 0xc7, 0x6b, 0xbb, 0x38, 0xe9, 0x50, 0x85, 0x6a, 0x41, 0xad, 0x31, 0xa8, 0x54, 0xe6, 0x02,
|
|
|
|
0x17, 0x47, 0x94, 0x03, 0x47, 0x4e, 0x1c, 0x38, 0x20, 0x84, 0x39, 0x83, 0xe4, 0xd8, 0x43, 0x64,
|
|
|
|
0x48, 0xbc, 0xcb, 0x7e, 0x54, 0xea, 0xd3, 0xf0, 0x66, 0x9c, 0x78, 0x0c, 0x0e, 0x78, 0x77, 0xbd,
|
|
|
|
0x26, 0xfe, 0x68, 0xd3, 0x53, 0xe6, 0x6b, 0x67, 0xe7, 0xff, 0xf3, 0x6c, 0x60, 0xc1, 0x51, 0x50,
|
|
|
|
0xc5, 0x0b, 0x4c, 0x19, 0xa7, 0x92, 0x92, 0x23, 0xa6, 0x36, 0x6a, 0x5b, 0x71, 0x56, 0xc4, 0x4f,
|
|
|
|
0xd6, 0x94, 0xae, 0x37, 0xb8, 0x34, 0x89, 0x95, 0xfa, 0xb6, 0xc4, 0x2d, 0x93, 0xd7, 0xb6, 0x2e,
|
|
|
|
0x7e, 0x3a, 0x4c, 0x0a, 0xc9, 0x55, 0x21, 0xdb, 0xec, 0xa2, 0xf9, 0xb9, 0xaa, 0x4a, 0xe4, 0xd6,
|
|
|
|
0x4f, 0x7e, 0x7b, 0xf0, 0x30, 0xc3, 0xbc, 0xcc, 0xda, 0xcb, 0x32, 0xfc, 0xa9, 0x50, 0x48, 0xb2,
|
|
|
|
0x00, 0xbf, 0x2a, 0x23, 0xef, 0xc2, 0x7b, 0x71, 0x94, 0x35, 0x16, 0x21, 0x70, 0x28, 0xaf, 0x19,
|
|
|
|
0x46, 0xbe, 0x89, 0x18, 0x5b, 0xc7, 0xea, 0x7c, 0x8b, 0x51, 0x60, 0x63, 0xda, 0x26, 0xa7, 0x10,
|
|
|
|
0xb2, 0x9c, 0x63, 0x2d, 0xa3, 0x43, 0x13, 0x6d, 0x3d, 0xf2, 0x06, 0xa0, 0xb9, 0x90, 0x21, 0x97,
|
|
|
|
0x15, 0x8a, 0xe8, 0x5e, 0x93, 0xbb, 0x7f, 0x79, 0x96, 0xda, 0x51, 0x53, 0x37, 0x6a, 0xfa, 0xd9,
|
|
|
|
0x8c, 0x9a, 0xed, 0x94, 0x92, 0x04, 0x8e, 0x4b, 0x64, 0x58, 0x97, 0x58, 0x17, 0xfa, 0x68, 0x78,
|
|
|
|
0x11, 0x34, 0x6d, 0x7b, 0x31, 0x12, 0xc3, 0xdc, 0xc9, 0x8a, 0x66, 0xe6, 0xda, 0xce, 0x4f, 0x72,
|
|
|
|
0x78, 0xd4, 0xd7, 0x27, 0x18, 0xad, 0x05, 0x92, 0x13, 0x08, 0x14, 0xaf, 0x5b, 0x85, 0xda, 0x1c,
|
|
|
|
0x8c, 0xe8, 0xdf, 0x79, 0xc4, 0xe4, 0xaf, 0x07, 0x67, 0x19, 0xae, 0x2b, 0x21, 0x91, 0x0f, 0x39,
|
|
|
|
0x3a, 0x6e, 0xde, 0x04, 0x37, 0x7f, 0x92, 0x5b, 0xd0, 0xe3, 0xd6, 0xc4, 0x0b, 0x25, 0x24, 0xdd,
|
|
|
|
0x1a, 0x9e, 0xf3, 0xac, 0xf5, 0xc8, 0x12, 0x42, 0xba, 0xfa, 0x8e, 0x85, 0xdc, 0xc7, 0xb2, 0x2d,
|
|
|
|
0x23, 0x11, 0xcc, 0x74, 0x4a, 0x9f, 0x08, 0x4d, 0x27, 0xe7, 0x8e, 0x08, 0xcf, 0xf6, 0x10, 0x9e,
|
|
|
|
0x0f, 0x08, 0xff, 0xf2, 0x20, 0x1a, 0xcb, 0xbf, 0x11, 0xb3, 0xdd, 0x2c, 0xbf, 0xdb, 0xac, 0xff,
|
|
|
|
0x4a, 0x82, 0xbb, 0x29, 0x69, 0x90, 0x08, 0x99, 0xaf, 0x36, 0xe8, 0x90, 0x58, 0x4f, 0x2b, 0xb4,
|
|
|
|
0x96, 0xde, 0x2f, 0x2d, 0xc1, 0xb9, 0x09, 0xc2, 0xf9, 0x70, 0xc0, 0x8f, 0x4a, 0x32, 0x25, 0x85,
|
|
|
|
0xfb, 0x4c, 0xe3, 0x31, 0x5f, 0xc1, 0x8c, 0xda, 0x9a, 0x7d, 0xab, 0xe0, 0xea, 0x2e, 0xff, 0xf8,
|
|
|
|
0xf0, 0xc0, 0xf5, 0xff, 0x40, 0xeb, 0x4a, 0x52, 0x4e, 0xde, 0x42, 0xf8, 0xbe, 0xbe, 0xa2, 0x3f,
|
|
|
|
0x9a, 0xf1, 0xd2, 0xee, 0x01, 0xa7, 0x36, 0xd4, 0x5e, 0x1e, 0x3f, 0x9e, 0xc8, 0x58, 0x7c, 0xc9,
|
|
|
|
0x01, 0xf9, 0x04, 0xc7, 0xbb, 0xfb, 0x4b, 0xce, 0x77, 0x8a, 0x27, 0x1e, 0x6e, 0xfc, 0xec, 0xc6,
|
|
|
|
0x7c, 0xd7, 0xf2, 0x0b, 0x9c, 0x0c, 0x71, 0x90, 0xa4, 0x77, 0x6c, 0x72, 0x97, 0xe3, 0xe7, 0xb7,
|
|
|
|
0xd6, 0x74, 0xed, 0xbf, 0x8e, 0x5f, 0x43, 0x4b, 0x9b, 0xbc, 0xbc, 0xa5, 0x43, 0xff, 0x8b, 0xc4,
|
|
|
|
0xa7, 0x23, 0xdc, 0xef, 0xf4, 0x9f, 0x5c, 0x72, 0xb0, 0x0a, 0x4d, 0xe4, 0xf5, 0xbf, 0x00, 0x00,
|
|
|
|
0x00, 0xff, 0xff, 0xa3, 0x97, 0x3d, 0x93, 0x21, 0x05, 0x00, 0x00,
|
2017-11-17 03:21:41 +01:00
|
|
|
}
|