pulumi/sdk/proto/go/resource.pb.go

2640 lines
127 KiB
Go
Raw Permalink Normal View History

// Copyright 2016-2022, Pulumi Corporation.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
// Code generated by protoc-gen-go. DO NOT EDIT.
// versions:
// protoc-gen-go v1.28.1
// protoc v3.20.1
// source: pulumi/resource.proto
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
package pulumirpc
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
import (
protoreflect "google.golang.org/protobuf/reflect/protoreflect"
protoimpl "google.golang.org/protobuf/runtime/protoimpl"
Plumb Remote, Component, and LogicalName into the import plugin system (#15199) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> Fixes https://github.com/pulumi/pulumi/issues/14532. 14532 was just for Remote and Component, but since raising that we've added LogicalName as well so this PR also adds support for that. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-01-24 17:15:30 +00:00
emptypb "google.golang.org/protobuf/types/known/emptypb"
structpb "google.golang.org/protobuf/types/known/structpb"
2023-03-04 22:11:52 +00:00
reflect "reflect"
sync "sync"
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
)
const (
// Verify that this generated code is sufficiently up-to-date.
_ = protoimpl.EnforceVersion(20 - protoimpl.MinVersion)
// Verify that runtime/protoimpl is sufficiently up-to-date.
_ = protoimpl.EnforceVersion(protoimpl.MaxVersion - 20)
)
type Result int32
const (
Result_SUCCESS Result = 0
Result_FAIL Result = 1
Result_SKIP Result = 2
)
// Enum value maps for Result.
var (
Result_name = map[int32]string{
0: "SUCCESS",
1: "FAIL",
2: "SKIP",
}
Result_value = map[string]int32{
"SUCCESS": 0,
"FAIL": 1,
"SKIP": 2,
}
)
func (x Result) Enum() *Result {
p := new(Result)
*p = x
return p
}
func (x Result) String() string {
return protoimpl.X.EnumStringOf(x.Descriptor(), protoreflect.EnumNumber(x))
}
func (Result) Descriptor() protoreflect.EnumDescriptor {
return file_pulumi_resource_proto_enumTypes[0].Descriptor()
}
func (Result) Type() protoreflect.EnumType {
return &file_pulumi_resource_proto_enumTypes[0]
}
func (x Result) Number() protoreflect.EnumNumber {
return protoreflect.EnumNumber(x)
}
// Deprecated: Use Result.Descriptor instead.
func (Result) EnumDescriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{0}
}
2019-04-12 18:27:18 +00:00
// SupportsFeatureRequest allows a client to test if the resource monitor supports a certain feature, which it may use
// to control the format or types of messages it sends.
type SupportsFeatureRequest struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
2019-04-12 18:27:18 +00:00
Id string `protobuf:"bytes,1,opt,name=id,proto3" json:"id,omitempty"` // the ID of the feature to test support for.
2019-04-12 18:27:18 +00:00
}
2020-02-28 11:53:47 +00:00
func (x *SupportsFeatureRequest) Reset() {
*x = SupportsFeatureRequest{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[0]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
2019-04-12 18:27:18 +00:00
}
func (x *SupportsFeatureRequest) String() string {
return protoimpl.X.MessageStringOf(x)
2019-04-12 18:27:18 +00:00
}
func (*SupportsFeatureRequest) ProtoMessage() {}
func (x *SupportsFeatureRequest) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[0]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
2019-04-12 18:27:18 +00:00
}
// Deprecated: Use SupportsFeatureRequest.ProtoReflect.Descriptor instead.
func (*SupportsFeatureRequest) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{0}
}
2019-04-12 18:27:18 +00:00
func (x *SupportsFeatureRequest) GetId() string {
if x != nil {
return x.Id
2019-04-12 18:27:18 +00:00
}
return ""
}
type SupportsFeatureResponse struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
2019-04-12 18:27:18 +00:00
HasSupport bool `protobuf:"varint,1,opt,name=hasSupport,proto3" json:"hasSupport,omitempty"` // true when the resource monitor supports this feature.
2019-04-12 18:27:18 +00:00
}
2020-02-28 11:53:47 +00:00
func (x *SupportsFeatureResponse) Reset() {
*x = SupportsFeatureResponse{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[1]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
2019-04-12 18:27:18 +00:00
}
func (x *SupportsFeatureResponse) String() string {
return protoimpl.X.MessageStringOf(x)
2019-04-12 18:27:18 +00:00
}
func (*SupportsFeatureResponse) ProtoMessage() {}
func (x *SupportsFeatureResponse) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[1]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
2019-04-12 18:27:18 +00:00
}
// Deprecated: Use SupportsFeatureResponse.ProtoReflect.Descriptor instead.
func (*SupportsFeatureResponse) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{1}
}
2019-04-12 18:27:18 +00:00
func (x *SupportsFeatureResponse) GetHasSupport() bool {
if x != nil {
return x.HasSupport
2019-04-12 18:27:18 +00:00
}
return false
}
// ReadResourceRequest contains enough information to uniquely qualify and read a resource's state.
type ReadResourceRequest struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
2020-02-28 11:53:47 +00:00
Pass provider checksums in requests and save to state (#13789) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This extends the resource monitor interface with fields for plugin checksums (on top of the existing plugin version and download url fields). These fields are threaded through the engine and are persisted in resource state. The sent or saved data is then used when installing plugins to ensure that the checksums match what was recorded at the time the SDK was built. Similar to https://github.com/pulumi/pulumi/pull/13776 nothing is using this yet, but this lays the engine side plumbing for them. ## Checklist - [ ] I have run `make tidy` to update any new dependencies - [ ] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-11 15:54:07 +00:00
Id string `protobuf:"bytes,1,opt,name=id,proto3" json:"id,omitempty"` // the ID of the resource to read.
Type string `protobuf:"bytes,2,opt,name=type,proto3" json:"type,omitempty"` // the type of the resource object.
Name string `protobuf:"bytes,3,opt,name=name,proto3" json:"name,omitempty"` // the name, for URN purposes, of the object.
Parent string `protobuf:"bytes,4,opt,name=parent,proto3" json:"parent,omitempty"` // an optional parent URN that this child resource belongs to.
Properties *structpb.Struct `protobuf:"bytes,5,opt,name=properties,proto3" json:"properties,omitempty"` // optional state sufficient to uniquely identify the resource.
Dependencies []string `protobuf:"bytes,6,rep,name=dependencies,proto3" json:"dependencies,omitempty"` // a list of URNs that this read depends on, as observed by the language host.
Provider string `protobuf:"bytes,7,opt,name=provider,proto3" json:"provider,omitempty"` // an optional reference to the provider to use for this read.
Version string `protobuf:"bytes,8,opt,name=version,proto3" json:"version,omitempty"` // the version of the provider to use when servicing this request.
AcceptSecrets bool `protobuf:"varint,9,opt,name=acceptSecrets,proto3" json:"acceptSecrets,omitempty"` // when true operations should return secrets as strongly typed.
AdditionalSecretOutputs []string `protobuf:"bytes,10,rep,name=additionalSecretOutputs,proto3" json:"additionalSecretOutputs,omitempty"` // a list of output properties that should also be treated as secret, in addition to ones we detect.
AcceptResources bool `protobuf:"varint,12,opt,name=acceptResources,proto3" json:"acceptResources,omitempty"` // when true operations should return resource references as strongly typed.
PluginDownloadURL string `protobuf:"bytes,13,opt,name=pluginDownloadURL,proto3" json:"pluginDownloadURL,omitempty"` // the server url of the provider to use when servicing this request.
PluginChecksums map[string][]byte `protobuf:"bytes,15,rep,name=pluginChecksums,proto3" json:"pluginChecksums,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"` // a map of checksums of the provider to use when servicing this request.
SourcePosition *SourcePosition `protobuf:"bytes,14,opt,name=sourcePosition,proto3" json:"sourcePosition,omitempty"` // the optional source position of the user code that initiated the read.
}
func (x *ReadResourceRequest) Reset() {
*x = ReadResourceRequest{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[2]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *ReadResourceRequest) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*ReadResourceRequest) ProtoMessage() {}
func (x *ReadResourceRequest) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[2]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use ReadResourceRequest.ProtoReflect.Descriptor instead.
func (*ReadResourceRequest) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{2}
}
func (x *ReadResourceRequest) GetId() string {
if x != nil {
return x.Id
}
return ""
}
func (x *ReadResourceRequest) GetType() string {
if x != nil {
return x.Type
}
return ""
}
func (x *ReadResourceRequest) GetName() string {
if x != nil {
return x.Name
}
return ""
}
func (x *ReadResourceRequest) GetParent() string {
if x != nil {
return x.Parent
}
return ""
}
func (x *ReadResourceRequest) GetProperties() *structpb.Struct {
if x != nil {
return x.Properties
}
return nil
}
func (x *ReadResourceRequest) GetDependencies() []string {
if x != nil {
return x.Dependencies
}
return nil
}
func (x *ReadResourceRequest) GetProvider() string {
if x != nil {
return x.Provider
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 00:50:29 +00:00
}
return ""
}
func (x *ReadResourceRequest) GetVersion() string {
if x != nil {
return x.Version
}
return ""
}
func (x *ReadResourceRequest) GetAcceptSecrets() bool {
if x != nil {
return x.AcceptSecrets
2019-04-12 18:27:18 +00:00
}
return false
}
func (x *ReadResourceRequest) GetAdditionalSecretOutputs() []string {
if x != nil {
return x.AdditionalSecretOutputs
2019-04-23 00:03:08 +00:00
}
return nil
}
func (x *ReadResourceRequest) GetAcceptResources() bool {
if x != nil {
return x.AcceptResources
}
return false
}
func (x *ReadResourceRequest) GetPluginDownloadURL() string {
if x != nil {
return x.PluginDownloadURL
}
return ""
}
Pass provider checksums in requests and save to state (#13789) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This extends the resource monitor interface with fields for plugin checksums (on top of the existing plugin version and download url fields). These fields are threaded through the engine and are persisted in resource state. The sent or saved data is then used when installing plugins to ensure that the checksums match what was recorded at the time the SDK was built. Similar to https://github.com/pulumi/pulumi/pull/13776 nothing is using this yet, but this lays the engine side plumbing for them. ## Checklist - [ ] I have run `make tidy` to update any new dependencies - [ ] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-11 15:54:07 +00:00
func (x *ReadResourceRequest) GetPluginChecksums() map[string][]byte {
if x != nil {
return x.PluginChecksums
}
return nil
}
[engine] Add support for source positions These changes add support for passing source position information in gRPC metadata and recording the source position that corresponds to a resource registration in the statefile. Enabling source position information in the resource model can provide substantial benefits, including but not limited to: - Better errors from the Pulumi CLI - Go-to-defintion for resources in state - Editor integration for errors, etc. from `pulumi preview` Source positions are (file, line) or (file, line, column) tuples represented as URIs. The line and column are stored in the fragment portion of the URI as "line(,column)?". The scheme of the URI and the form of its path component depends on the context in which it is generated or used: - During an active update, the URI's scheme is `file` and paths are absolute filesystem paths. This allows consumers to easily access arbitrary files that are available on the host. - In a statefile, the URI's scheme is `project` and paths are relative to the project root. This allows consumers to resolve source positions relative to the project file in different contexts irrespective of the location of the project itself (e.g. given a project-relative path and the URL of the project's root on GitHub, one can build a GitHub URL for the source position). During an update, source position information may be attached to gRPC calls as "source-position" metadata. This allows arbitrary calls to be associated with source positions without changes to their protobuf payloads. Modifying the protobuf payloads is also a viable approach, but is somewhat more invasive than attaching metadata, and requires changes to every call signature. Source positions should reflect the position in user code that initiated a resource model operation (e.g. the source position passed with `RegisterResource` for `pet` in the example above should be the source position in `index.ts`, _not_ the source position in the Pulumi SDK). In general, the Pulumi SDK should be able to infer the source position of the resource registration, as the relationship between a resource registration and its corresponding user code should be static per SDK. Source positions in state files will be stored as a new `registeredAt` property on each resource. This property is optional.
2023-06-29 18:41:19 +00:00
func (x *ReadResourceRequest) GetSourcePosition() *SourcePosition {
if x != nil {
return x.SourcePosition
}
return nil
}
// ReadResourceResponse contains the result of reading a resource's state.
type ReadResourceResponse struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Urn string `protobuf:"bytes,1,opt,name=urn,proto3" json:"urn,omitempty"` // the URN for this resource.
Properties *structpb.Struct `protobuf:"bytes,2,opt,name=properties,proto3" json:"properties,omitempty"` // the state of the resource read from the live environment.
}
2020-02-28 11:53:47 +00:00
func (x *ReadResourceResponse) Reset() {
*x = ReadResourceResponse{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[3]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *ReadResourceResponse) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*ReadResourceResponse) ProtoMessage() {}
func (x *ReadResourceResponse) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[3]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use ReadResourceResponse.ProtoReflect.Descriptor instead.
func (*ReadResourceResponse) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{3}
}
func (x *ReadResourceResponse) GetUrn() string {
if x != nil {
return x.Urn
}
return ""
}
func (x *ReadResourceResponse) GetProperties() *structpb.Struct {
if x != nil {
return x.Properties
}
return nil
}
// RegisterResourceRequest contains information about a resource object that was newly allocated.
type RegisterResourceRequest struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Type string `protobuf:"bytes,1,opt,name=type,proto3" json:"type,omitempty"` // the type of the object allocated.
Name string `protobuf:"bytes,2,opt,name=name,proto3" json:"name,omitempty"` // the name, for URN purposes, of the object.
Parent string `protobuf:"bytes,3,opt,name=parent,proto3" json:"parent,omitempty"` // an optional parent URN that this child resource belongs to.
Custom bool `protobuf:"varint,4,opt,name=custom,proto3" json:"custom,omitempty"` // true if the resource is a custom, managed by a plugin's CRUD operations.
Object *structpb.Struct `protobuf:"bytes,5,opt,name=object,proto3" json:"object,omitempty"` // an object produced by the interpreter/source.
Protect bool `protobuf:"varint,6,opt,name=protect,proto3" json:"protect,omitempty"` // true if the resource should be marked protected.
Dependencies []string `protobuf:"bytes,7,rep,name=dependencies,proto3" json:"dependencies,omitempty"` // a list of URNs that this resource depends on, as observed by the language host.
Provider string `protobuf:"bytes,8,opt,name=provider,proto3" json:"provider,omitempty"` // an optional reference to the provider to manage this resource's CRUD operations.
PropertyDependencies map[string]*RegisterResourceRequest_PropertyDependencies `protobuf:"bytes,9,rep,name=propertyDependencies,proto3" json:"propertyDependencies,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"` // a map from property keys to the dependencies of the property.
DeleteBeforeReplace bool `protobuf:"varint,10,opt,name=deleteBeforeReplace,proto3" json:"deleteBeforeReplace,omitempty"` // true if this resource should be deleted before replacement.
Version string `protobuf:"bytes,11,opt,name=version,proto3" json:"version,omitempty"` // the version of the provider to use when servicing this request.
IgnoreChanges []string `protobuf:"bytes,12,rep,name=ignoreChanges,proto3" json:"ignoreChanges,omitempty"` // a list of property selectors to ignore during updates.
AcceptSecrets bool `protobuf:"varint,13,opt,name=acceptSecrets,proto3" json:"acceptSecrets,omitempty"` // when true operations should return secrets as strongly typed.
AdditionalSecretOutputs []string `protobuf:"bytes,14,rep,name=additionalSecretOutputs,proto3" json:"additionalSecretOutputs,omitempty"` // a list of output properties that should also be treated as secret, in addition to ones we detect.
AliasURNs []string `protobuf:"bytes,15,rep,name=aliasURNs,proto3" json:"aliasURNs,omitempty"` // a list of additional URNs that should be considered the same.
ImportId string `protobuf:"bytes,16,opt,name=importId,proto3" json:"importId,omitempty"` // if set, this resource's state should be imported from the given ID.
CustomTimeouts *RegisterResourceRequest_CustomTimeouts `protobuf:"bytes,17,opt,name=customTimeouts,proto3" json:"customTimeouts,omitempty"` // ability to pass a custom Timeout block.
DeleteBeforeReplaceDefined bool `protobuf:"varint,18,opt,name=deleteBeforeReplaceDefined,proto3" json:"deleteBeforeReplaceDefined,omitempty"` // true if the deleteBeforeReplace property should be treated as defined even if it is false.
SupportsPartialValues bool `protobuf:"varint,19,opt,name=supportsPartialValues,proto3" json:"supportsPartialValues,omitempty"` // true if the request is from an SDK that supports partially-known properties during preview.
Remote bool `protobuf:"varint,20,opt,name=remote,proto3" json:"remote,omitempty"` // true if the resource is a plugin-managed component resource.
AcceptResources bool `protobuf:"varint,21,opt,name=acceptResources,proto3" json:"acceptResources,omitempty"` // when true operations should return resource references as strongly typed.
Providers map[string]string `protobuf:"bytes,22,rep,name=providers,proto3" json:"providers,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"` // an optional reference to the provider map to manage this resource's CRUD operations.
ReplaceOnChanges []string `protobuf:"bytes,23,rep,name=replaceOnChanges,proto3" json:"replaceOnChanges,omitempty"` // a list of properties that if changed should force a replacement.
PluginDownloadURL string `protobuf:"bytes,24,opt,name=pluginDownloadURL,proto3" json:"pluginDownloadURL,omitempty"` // the server URL of the provider to use when servicing this request.
Pass provider checksums in requests and save to state (#13789) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This extends the resource monitor interface with fields for plugin checksums (on top of the existing plugin version and download url fields). These fields are threaded through the engine and are persisted in resource state. The sent or saved data is then used when installing plugins to ensure that the checksums match what was recorded at the time the SDK was built. Similar to https://github.com/pulumi/pulumi/pull/13776 nothing is using this yet, but this lays the engine side plumbing for them. ## Checklist - [ ] I have run `make tidy` to update any new dependencies - [ ] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-11 15:54:07 +00:00
PluginChecksums map[string][]byte `protobuf:"bytes,30,rep,name=pluginChecksums,proto3" json:"pluginChecksums,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"` // a map of checksums expected for the provider plugin.
RetainOnDelete bool `protobuf:"varint,25,opt,name=retainOnDelete,proto3" json:"retainOnDelete,omitempty"` // if true the engine will not call the resource providers delete method for this resource.
Aliases []*Alias `protobuf:"bytes,26,rep,name=aliases,proto3" json:"aliases,omitempty"` // a list of additional aliases that should be considered the same.
DeletedWith string `protobuf:"bytes,27,opt,name=deletedWith,proto3" json:"deletedWith,omitempty"` // if set the engine will not call the resource providers delete method for this resource when specified resource is deleted.
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
CreateIfNotExists string `protobuf:"bytes,34,opt,name=createIfNotExists,proto3" json:"createIfNotExists,omitempty"` // if set, this resource should be created if and only if the specified ID does not exist in the provider.
// Indicates that alias specs are specified correctly according to the spec.
// Older versions of the Node.js SDK did not send alias specs correctly.
// If this is not set to true and the engine detects the request is from the
// Node.js runtime, the engine will transform incorrect alias specs into
// correct ones.
// Other SDKs that are correctly specifying alias specs could set this to
// true, but it's not necessary.
AliasSpecs bool `protobuf:"varint,28,opt,name=aliasSpecs,proto3" json:"aliasSpecs,omitempty"`
SourcePosition *SourcePosition `protobuf:"bytes,29,opt,name=sourcePosition,proto3" json:"sourcePosition,omitempty"` // the optional source position of the user code that initiated the register.
Transforms []*Callback `protobuf:"bytes,31,rep,name=transforms,proto3" json:"transforms,omitempty"` // a list of transforms to apply to the resource before registering it.
SupportsResultReporting bool `protobuf:"varint,32,opt,name=supportsResultReporting,proto3" json:"supportsResultReporting,omitempty"` // true if the request is from an SDK that supports the result field in the response.
Package string `protobuf:"bytes,33,opt,name=package,proto3" json:"package,omitempty"` // a reference from RegisterProviderRequest.
}
func (x *RegisterResourceRequest) Reset() {
*x = RegisterResourceRequest{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[4]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *RegisterResourceRequest) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*RegisterResourceRequest) ProtoMessage() {}
func (x *RegisterResourceRequest) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[4]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use RegisterResourceRequest.ProtoReflect.Descriptor instead.
func (*RegisterResourceRequest) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{4}
}
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
func (x *RegisterResourceRequest) GetType() string {
if x != nil {
return x.Type
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
return ""
}
func (x *RegisterResourceRequest) GetName() string {
if x != nil {
return x.Name
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
return ""
}
func (x *RegisterResourceRequest) GetParent() string {
if x != nil {
return x.Parent
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
return ""
}
func (x *RegisterResourceRequest) GetCustom() bool {
if x != nil {
return x.Custom
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
return false
}
func (x *RegisterResourceRequest) GetObject() *structpb.Struct {
if x != nil {
return x.Object
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
return nil
}
func (x *RegisterResourceRequest) GetProtect() bool {
if x != nil {
return x.Protect
}
return false
}
func (x *RegisterResourceRequest) GetDependencies() []string {
if x != nil {
return x.Dependencies
}
return nil
}
func (x *RegisterResourceRequest) GetProvider() string {
if x != nil {
return x.Provider
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 00:50:29 +00:00
}
return ""
}
func (x *RegisterResourceRequest) GetPropertyDependencies() map[string]*RegisterResourceRequest_PropertyDependencies {
if x != nil {
return x.PropertyDependencies
Implement more precise delete-before-replace semantics. (#2369) This implements the new algorithm for deciding which resources must be deleted due to a delete-before-replace operation. We need to compute the set of resources that may be replaced by a change to the resource under consideration. We do this by taking the complete set of transitive dependents on the resource under consideration and removing any resources that would not be replaced by changes to their dependencies. We determine whether or not a resource may be replaced by substituting unknowns for input properties that may change due to deletion of the resources their value depends on and calling the resource provider's Diff method. This is perhaps clearer when described by example. Consider the following dependency graph: A __|__ B C | _|_ D E F In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the specific properties of any of those resources R that would occur if a resource on the path to A were deleted and recreated may not cause R to be replaced. For example, the edge from B to A may be a simple dependsOn edge such that a change to B does not actually influence any of B's input properties. In that case, neither B nor D would need to be deleted before A could be deleted. In order to make the above algorithm a reality, the resource monitor interface has been updated to include a map that associates an input property key with the list of resources that input property depends on. Older clients of the resource monitor will leave this map empty, in which case all input properties will be treated as depending on all dependencies of the resource. This is probably overly conservative, but it is less conservative than what we currently implement, and is certainly correct.
2019-01-28 17:46:30 +00:00
}
return nil
}
func (x *RegisterResourceRequest) GetDeleteBeforeReplace() bool {
if x != nil {
return x.DeleteBeforeReplace
}
return false
}
func (x *RegisterResourceRequest) GetVersion() string {
if x != nil {
return x.Version
}
return ""
}
func (x *RegisterResourceRequest) GetIgnoreChanges() []string {
if x != nil {
return x.IgnoreChanges
}
return nil
}
func (x *RegisterResourceRequest) GetAcceptSecrets() bool {
if x != nil {
return x.AcceptSecrets
2019-04-12 18:27:18 +00:00
}
return false
}
func (x *RegisterResourceRequest) GetAdditionalSecretOutputs() []string {
if x != nil {
return x.AdditionalSecretOutputs
2019-04-23 00:03:08 +00:00
}
return nil
}
func (x *RegisterResourceRequest) GetAliasURNs() []string {
if x != nil {
return x.AliasURNs
Support aliases for renaming, re-typing, or re-parenting resources (#2774) Adds a new resource option `aliases` which can be used to rename a resource. When making a breaking change to the name or type of a resource or component, the old name can be added to the list of `aliases` for a resource to ensure that existing resources will be migrated to the new name instead of being deleted and replaced with the new named resource. There are two key places this change is implemented. The first is the step generator in the engine. When computing whether there is an old version of a registered resource, we now take into account the aliases specified on the registered resource. That is, we first look up the resource by its new URN in the old state, and then by any aliases provided (in order). This can allow the resource to be matched as a (potential) update to an existing resource with a different URN. The second is the core `Resource` constructor in the JavaScript (and soon Python) SDKs. This change ensures that when a parent resource is aliased, that all children implicitly inherit corresponding aliases. It is similar to how many other resource options are "inherited" implicitly from the parent. Four specific scenarios are explicitly tested as part of this PR: 1. Renaming a resource 2. Adopting a resource into a component (as the owner of both component and consumption codebases) 3. Renaming a component instance (as the owner of the consumption codebase without changes to the component) 4. Changing the type of a component (as the owner of the component codebase without changes to the consumption codebase) 4. Combining (1) and (3) to make both changes to a resource at the same time
2019-06-01 06:01:01 +00:00
}
return nil
}
func (x *RegisterResourceRequest) GetImportId() string {
if x != nil {
return x.ImportId
}
return ""
}
func (x *RegisterResourceRequest) GetCustomTimeouts() *RegisterResourceRequest_CustomTimeouts {
if x != nil {
return x.CustomTimeouts
2019-07-15 21:26:28 +00:00
}
return nil
}
func (x *RegisterResourceRequest) GetDeleteBeforeReplaceDefined() bool {
if x != nil {
return x.DeleteBeforeReplaceDefined
}
return false
}
func (x *RegisterResourceRequest) GetSupportsPartialValues() bool {
if x != nil {
return x.SupportsPartialValues
Propagate inputs to outputs during preview. (#3327) These changes restore a more-correct version of the behavior that was disabled with #3014. The original implementation of this behavior was done in the SDKs, which do not have access to the complete inputs for a resource (in particular, default values filled in by the provider during `Check` are not exposed to the SDK). This lack of information meant that the resolved output values could disagree with the typings present in a provider SDK. Exacerbating this problem was the fact that unknown values were dropped entirely, causing `undefined` values to appear in unexpected places. By doing this in the engine and allowing unknown values to be represented in a first-class manner in the SDK, we can attack both of these issues. Although this behavior is not _strictly_ consistent with respect to the resource model--in an update, a resource's output properties will come from its provider and may differ from its input properties--this behavior was present in the product for a fairly long time without significant issues. In the future, we may be able to improve the accuracy of resource outputs during a preview by allowing the provider to dry-run CRUD operations and return partially-known values where possible. These changes also introduce new APIs in the Node and Python SDKs that work with unknown values in a first-class fashion: - A new parameter to the `apply` function that indicates that the callback should be run even if the result of the apply contains unknown values - `containsUnknowns` and `isUnknown`, which return true if a value either contains nested unknown values or is exactly an unknown value - The `Unknown` type, which represents unknown values The primary use case for these APIs is to allow nested, properties with known values to be accessed via the lifted property accessor even when the containing property is not fully know. A common example of this pattern is the `metadata.name` property of a Kubernetes `Namespace` object: while other properties of the `metadata` bag may be unknown, `name` is often known. These APIs allow `ns.metadata.name` to return a known value in this case. In order to avoid exposing downlevel SDKs to unknown values--a change which could break user code by exposing it to unexpected values--a language SDK must indicate whether or not it supports first-class unknown values as part of each `RegisterResourceRequest`. These changes also allow us to avoid breaking user code with the new behavior introduced by the prior commit. Fixes #3190.
2019-11-11 20:09:34 +00:00
}
return false
}
func (x *RegisterResourceRequest) GetRemote() bool {
if x != nil {
return x.Remote
Initial support for remote component construction. (#5280) 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.
2020-09-08 02:33:55 +00:00
}
return false
}
func (x *RegisterResourceRequest) GetAcceptResources() bool {
if x != nil {
return x.AcceptResources
}
return false
}
func (x *RegisterResourceRequest) GetProviders() map[string]string {
if x != nil {
return x.Providers
}
return nil
}
func (x *RegisterResourceRequest) GetReplaceOnChanges() []string {
if x != nil {
return x.ReplaceOnChanges
}
return nil
}
func (x *RegisterResourceRequest) GetPluginDownloadURL() string {
if x != nil {
return x.PluginDownloadURL
}
return ""
}
Pass provider checksums in requests and save to state (#13789) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This extends the resource monitor interface with fields for plugin checksums (on top of the existing plugin version and download url fields). These fields are threaded through the engine and are persisted in resource state. The sent or saved data is then used when installing plugins to ensure that the checksums match what was recorded at the time the SDK was built. Similar to https://github.com/pulumi/pulumi/pull/13776 nothing is using this yet, but this lays the engine side plumbing for them. ## Checklist - [ ] I have run `make tidy` to update any new dependencies - [ ] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-11 15:54:07 +00:00
func (x *RegisterResourceRequest) GetPluginChecksums() map[string][]byte {
if x != nil {
return x.PluginChecksums
}
return nil
}
func (x *RegisterResourceRequest) GetRetainOnDelete() bool {
if x != nil {
return x.RetainOnDelete
}
return false
}
func (x *RegisterResourceRequest) GetAliases() []*Alias {
if x != nil {
return x.Aliases
}
return nil
}
func (x *RegisterResourceRequest) GetDeletedWith() string {
if x != nil {
return x.DeletedWith
}
return ""
}
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
func (x *RegisterResourceRequest) GetCreateIfNotExists() string {
if x != nil {
return x.CreateIfNotExists
}
return ""
}
func (x *RegisterResourceRequest) GetAliasSpecs() bool {
if x != nil {
return x.AliasSpecs
}
return false
}
[engine] Add support for source positions These changes add support for passing source position information in gRPC metadata and recording the source position that corresponds to a resource registration in the statefile. Enabling source position information in the resource model can provide substantial benefits, including but not limited to: - Better errors from the Pulumi CLI - Go-to-defintion for resources in state - Editor integration for errors, etc. from `pulumi preview` Source positions are (file, line) or (file, line, column) tuples represented as URIs. The line and column are stored in the fragment portion of the URI as "line(,column)?". The scheme of the URI and the form of its path component depends on the context in which it is generated or used: - During an active update, the URI's scheme is `file` and paths are absolute filesystem paths. This allows consumers to easily access arbitrary files that are available on the host. - In a statefile, the URI's scheme is `project` and paths are relative to the project root. This allows consumers to resolve source positions relative to the project file in different contexts irrespective of the location of the project itself (e.g. given a project-relative path and the URL of the project's root on GitHub, one can build a GitHub URL for the source position). During an update, source position information may be attached to gRPC calls as "source-position" metadata. This allows arbitrary calls to be associated with source positions without changes to their protobuf payloads. Modifying the protobuf payloads is also a viable approach, but is somewhat more invasive than attaching metadata, and requires changes to every call signature. Source positions should reflect the position in user code that initiated a resource model operation (e.g. the source position passed with `RegisterResource` for `pet` in the example above should be the source position in `index.ts`, _not_ the source position in the Pulumi SDK). In general, the Pulumi SDK should be able to infer the source position of the resource registration, as the relationship between a resource registration and its corresponding user code should be static per SDK. Source positions in state files will be stored as a new `registeredAt` property on each resource. This property is optional.
2023-06-29 18:41:19 +00:00
func (x *RegisterResourceRequest) GetSourcePosition() *SourcePosition {
if x != nil {
return x.SourcePosition
}
return nil
}
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
func (x *RegisterResourceRequest) GetTransforms() []*Callback {
if x != nil {
return x.Transforms
}
return nil
}
func (x *RegisterResourceRequest) GetSupportsResultReporting() bool {
if x != nil {
return x.SupportsResultReporting
}
return false
}
func (x *RegisterResourceRequest) GetPackage() string {
if x != nil {
return x.Package
}
return ""
}
// 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 {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Implement more precise delete-before-replace semantics. (#2369) This implements the new algorithm for deciding which resources must be deleted due to a delete-before-replace operation. We need to compute the set of resources that may be replaced by a change to the resource under consideration. We do this by taking the complete set of transitive dependents on the resource under consideration and removing any resources that would not be replaced by changes to their dependencies. We determine whether or not a resource may be replaced by substituting unknowns for input properties that may change due to deletion of the resources their value depends on and calling the resource provider's Diff method. This is perhaps clearer when described by example. Consider the following dependency graph: A __|__ B C | _|_ D E F In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the specific properties of any of those resources R that would occur if a resource on the path to A were deleted and recreated may not cause R to be replaced. For example, the edge from B to A may be a simple dependsOn edge such that a change to B does not actually influence any of B's input properties. In that case, neither B nor D would need to be deleted before A could be deleted. In order to make the above algorithm a reality, the resource monitor interface has been updated to include a map that associates an input property key with the list of resources that input property depends on. Older clients of the resource monitor will leave this map empty, in which case all input properties will be treated as depending on all dependencies of the resource. This is probably overly conservative, but it is less conservative than what we currently implement, and is certainly correct.
2019-01-28 17:46:30 +00:00
Urn string `protobuf:"bytes,1,opt,name=urn,proto3" json:"urn,omitempty"` // the URN assigned by the engine.
Id string `protobuf:"bytes,2,opt,name=id,proto3" json:"id,omitempty"` // the unique ID assigned by the provider.
Object *structpb.Struct `protobuf:"bytes,3,opt,name=object,proto3" json:"object,omitempty"` // the resulting object properties, including provider defaults.
Stable bool `protobuf:"varint,4,opt,name=stable,proto3" json:"stable,omitempty"` // if true, the object's state is stable and may be trusted not to change.
Stables []string `protobuf:"bytes,5,rep,name=stables,proto3" json:"stables,omitempty"` // an optional list of guaranteed-stable properties.
PropertyDependencies map[string]*RegisterResourceResponse_PropertyDependencies `protobuf:"bytes,6,rep,name=propertyDependencies,proto3" json:"propertyDependencies,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"` // a map from property keys to the dependencies of the property.
Result Result `protobuf:"varint,7,opt,name=result,proto3,enum=pulumirpc.Result" json:"result,omitempty"` // the reason, whether the resource registration was successful, failed, or skipped.
Implement more precise delete-before-replace semantics. (#2369) This implements the new algorithm for deciding which resources must be deleted due to a delete-before-replace operation. We need to compute the set of resources that may be replaced by a change to the resource under consideration. We do this by taking the complete set of transitive dependents on the resource under consideration and removing any resources that would not be replaced by changes to their dependencies. We determine whether or not a resource may be replaced by substituting unknowns for input properties that may change due to deletion of the resources their value depends on and calling the resource provider's Diff method. This is perhaps clearer when described by example. Consider the following dependency graph: A __|__ B C | _|_ D E F In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the specific properties of any of those resources R that would occur if a resource on the path to A were deleted and recreated may not cause R to be replaced. For example, the edge from B to A may be a simple dependsOn edge such that a change to B does not actually influence any of B's input properties. In that case, neither B nor D would need to be deleted before A could be deleted. In order to make the above algorithm a reality, the resource monitor interface has been updated to include a map that associates an input property key with the list of resources that input property depends on. Older clients of the resource monitor will leave this map empty, in which case all input properties will be treated as depending on all dependencies of the resource. This is probably overly conservative, but it is less conservative than what we currently implement, and is certainly correct.
2019-01-28 17:46:30 +00:00
}
2020-02-28 11:53:47 +00:00
func (x *RegisterResourceResponse) Reset() {
*x = RegisterResourceResponse{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[5]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
Implement more precise delete-before-replace semantics. (#2369) This implements the new algorithm for deciding which resources must be deleted due to a delete-before-replace operation. We need to compute the set of resources that may be replaced by a change to the resource under consideration. We do this by taking the complete set of transitive dependents on the resource under consideration and removing any resources that would not be replaced by changes to their dependencies. We determine whether or not a resource may be replaced by substituting unknowns for input properties that may change due to deletion of the resources their value depends on and calling the resource provider's Diff method. This is perhaps clearer when described by example. Consider the following dependency graph: A __|__ B C | _|_ D E F In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the specific properties of any of those resources R that would occur if a resource on the path to A were deleted and recreated may not cause R to be replaced. For example, the edge from B to A may be a simple dependsOn edge such that a change to B does not actually influence any of B's input properties. In that case, neither B nor D would need to be deleted before A could be deleted. In order to make the above algorithm a reality, the resource monitor interface has been updated to include a map that associates an input property key with the list of resources that input property depends on. Older clients of the resource monitor will leave this map empty, in which case all input properties will be treated as depending on all dependencies of the resource. This is probably overly conservative, but it is less conservative than what we currently implement, and is certainly correct.
2019-01-28 17:46:30 +00:00
}
func (x *RegisterResourceResponse) String() string {
return protoimpl.X.MessageStringOf(x)
Implement more precise delete-before-replace semantics. (#2369) This implements the new algorithm for deciding which resources must be deleted due to a delete-before-replace operation. We need to compute the set of resources that may be replaced by a change to the resource under consideration. We do this by taking the complete set of transitive dependents on the resource under consideration and removing any resources that would not be replaced by changes to their dependencies. We determine whether or not a resource may be replaced by substituting unknowns for input properties that may change due to deletion of the resources their value depends on and calling the resource provider's Diff method. This is perhaps clearer when described by example. Consider the following dependency graph: A __|__ B C | _|_ D E F In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the specific properties of any of those resources R that would occur if a resource on the path to A were deleted and recreated may not cause R to be replaced. For example, the edge from B to A may be a simple dependsOn edge such that a change to B does not actually influence any of B's input properties. In that case, neither B nor D would need to be deleted before A could be deleted. In order to make the above algorithm a reality, the resource monitor interface has been updated to include a map that associates an input property key with the list of resources that input property depends on. Older clients of the resource monitor will leave this map empty, in which case all input properties will be treated as depending on all dependencies of the resource. This is probably overly conservative, but it is less conservative than what we currently implement, and is certainly correct.
2019-01-28 17:46:30 +00:00
}
func (*RegisterResourceResponse) ProtoMessage() {}
func (x *RegisterResourceResponse) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[5]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
Implement more precise delete-before-replace semantics. (#2369) This implements the new algorithm for deciding which resources must be deleted due to a delete-before-replace operation. We need to compute the set of resources that may be replaced by a change to the resource under consideration. We do this by taking the complete set of transitive dependents on the resource under consideration and removing any resources that would not be replaced by changes to their dependencies. We determine whether or not a resource may be replaced by substituting unknowns for input properties that may change due to deletion of the resources their value depends on and calling the resource provider's Diff method. This is perhaps clearer when described by example. Consider the following dependency graph: A __|__ B C | _|_ D E F In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the specific properties of any of those resources R that would occur if a resource on the path to A were deleted and recreated may not cause R to be replaced. For example, the edge from B to A may be a simple dependsOn edge such that a change to B does not actually influence any of B's input properties. In that case, neither B nor D would need to be deleted before A could be deleted. In order to make the above algorithm a reality, the resource monitor interface has been updated to include a map that associates an input property key with the list of resources that input property depends on. Older clients of the resource monitor will leave this map empty, in which case all input properties will be treated as depending on all dependencies of the resource. This is probably overly conservative, but it is less conservative than what we currently implement, and is certainly correct.
2019-01-28 17:46:30 +00:00
}
// Deprecated: Use RegisterResourceResponse.ProtoReflect.Descriptor instead.
func (*RegisterResourceResponse) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{5}
Implement more precise delete-before-replace semantics. (#2369) This implements the new algorithm for deciding which resources must be deleted due to a delete-before-replace operation. We need to compute the set of resources that may be replaced by a change to the resource under consideration. We do this by taking the complete set of transitive dependents on the resource under consideration and removing any resources that would not be replaced by changes to their dependencies. We determine whether or not a resource may be replaced by substituting unknowns for input properties that may change due to deletion of the resources their value depends on and calling the resource provider's Diff method. This is perhaps clearer when described by example. Consider the following dependency graph: A __|__ B C | _|_ D E F In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the specific properties of any of those resources R that would occur if a resource on the path to A were deleted and recreated may not cause R to be replaced. For example, the edge from B to A may be a simple dependsOn edge such that a change to B does not actually influence any of B's input properties. In that case, neither B nor D would need to be deleted before A could be deleted. In order to make the above algorithm a reality, the resource monitor interface has been updated to include a map that associates an input property key with the list of resources that input property depends on. Older clients of the resource monitor will leave this map empty, in which case all input properties will be treated as depending on all dependencies of the resource. This is probably overly conservative, but it is less conservative than what we currently implement, and is certainly correct.
2019-01-28 17:46:30 +00:00
}
func (x *RegisterResourceResponse) GetUrn() string {
if x != nil {
return x.Urn
}
return ""
Implement more precise delete-before-replace semantics. (#2369) This implements the new algorithm for deciding which resources must be deleted due to a delete-before-replace operation. We need to compute the set of resources that may be replaced by a change to the resource under consideration. We do this by taking the complete set of transitive dependents on the resource under consideration and removing any resources that would not be replaced by changes to their dependencies. We determine whether or not a resource may be replaced by substituting unknowns for input properties that may change due to deletion of the resources their value depends on and calling the resource provider's Diff method. This is perhaps clearer when described by example. Consider the following dependency graph: A __|__ B C | _|_ D E F In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the specific properties of any of those resources R that would occur if a resource on the path to A were deleted and recreated may not cause R to be replaced. For example, the edge from B to A may be a simple dependsOn edge such that a change to B does not actually influence any of B's input properties. In that case, neither B nor D would need to be deleted before A could be deleted. In order to make the above algorithm a reality, the resource monitor interface has been updated to include a map that associates an input property key with the list of resources that input property depends on. Older clients of the resource monitor will leave this map empty, in which case all input properties will be treated as depending on all dependencies of the resource. This is probably overly conservative, but it is less conservative than what we currently implement, and is certainly correct.
2019-01-28 17:46:30 +00:00
}
func (x *RegisterResourceResponse) GetId() string {
if x != nil {
return x.Id
}
return ""
}
Implement more precise delete-before-replace semantics. (#2369) This implements the new algorithm for deciding which resources must be deleted due to a delete-before-replace operation. We need to compute the set of resources that may be replaced by a change to the resource under consideration. We do this by taking the complete set of transitive dependents on the resource under consideration and removing any resources that would not be replaced by changes to their dependencies. We determine whether or not a resource may be replaced by substituting unknowns for input properties that may change due to deletion of the resources their value depends on and calling the resource provider's Diff method. This is perhaps clearer when described by example. Consider the following dependency graph: A __|__ B C | _|_ D E F In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the specific properties of any of those resources R that would occur if a resource on the path to A were deleted and recreated may not cause R to be replaced. For example, the edge from B to A may be a simple dependsOn edge such that a change to B does not actually influence any of B's input properties. In that case, neither B nor D would need to be deleted before A could be deleted. In order to make the above algorithm a reality, the resource monitor interface has been updated to include a map that associates an input property key with the list of resources that input property depends on. Older clients of the resource monitor will leave this map empty, in which case all input properties will be treated as depending on all dependencies of the resource. This is probably overly conservative, but it is less conservative than what we currently implement, and is certainly correct.
2019-01-28 17:46:30 +00:00
func (x *RegisterResourceResponse) GetObject() *structpb.Struct {
if x != nil {
return x.Object
Implement more precise delete-before-replace semantics. (#2369) This implements the new algorithm for deciding which resources must be deleted due to a delete-before-replace operation. We need to compute the set of resources that may be replaced by a change to the resource under consideration. We do this by taking the complete set of transitive dependents on the resource under consideration and removing any resources that would not be replaced by changes to their dependencies. We determine whether or not a resource may be replaced by substituting unknowns for input properties that may change due to deletion of the resources their value depends on and calling the resource provider's Diff method. This is perhaps clearer when described by example. Consider the following dependency graph: A __|__ B C | _|_ D E F In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the specific properties of any of those resources R that would occur if a resource on the path to A were deleted and recreated may not cause R to be replaced. For example, the edge from B to A may be a simple dependsOn edge such that a change to B does not actually influence any of B's input properties. In that case, neither B nor D would need to be deleted before A could be deleted. In order to make the above algorithm a reality, the resource monitor interface has been updated to include a map that associates an input property key with the list of resources that input property depends on. Older clients of the resource monitor will leave this map empty, in which case all input properties will be treated as depending on all dependencies of the resource. This is probably overly conservative, but it is less conservative than what we currently implement, and is certainly correct.
2019-01-28 17:46:30 +00:00
}
return nil
}
func (x *RegisterResourceResponse) GetStable() bool {
if x != nil {
return x.Stable
}
return false
2019-07-15 21:26:28 +00:00
}
func (x *RegisterResourceResponse) GetStables() []string {
if x != nil {
return x.Stables
}
return nil
2019-07-15 21:26:28 +00:00
}
2020-02-28 11:53:47 +00:00
func (x *RegisterResourceResponse) GetPropertyDependencies() map[string]*RegisterResourceResponse_PropertyDependencies {
if x != nil {
return x.PropertyDependencies
}
return nil
2019-07-15 21:26:28 +00:00
}
func (x *RegisterResourceResponse) GetResult() Result {
if x != nil {
return x.Result
}
return Result_SUCCESS
}
// RegisterResourceOutputsRequest adds extra resource outputs created by the program after registration has occurred.
type RegisterResourceOutputsRequest struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Urn string `protobuf:"bytes,1,opt,name=urn,proto3" json:"urn,omitempty"` // the URN for the resource to attach output properties to.
Outputs *structpb.Struct `protobuf:"bytes,2,opt,name=outputs,proto3" json:"outputs,omitempty"` // additional output properties to add to the existing resource.
2019-07-15 21:26:28 +00:00
}
func (x *RegisterResourceOutputsRequest) Reset() {
*x = RegisterResourceOutputsRequest{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[6]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
2019-07-15 21:26:28 +00:00
}
func (x *RegisterResourceOutputsRequest) String() string {
return protoimpl.X.MessageStringOf(x)
2019-07-15 21:26:28 +00:00
}
func (*RegisterResourceOutputsRequest) ProtoMessage() {}
2019-07-15 21:26:28 +00:00
func (x *RegisterResourceOutputsRequest) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[6]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
2019-07-15 21:26:28 +00:00
}
return mi.MessageOf(x)
2019-07-15 21:26:28 +00:00
}
// Deprecated: Use RegisterResourceOutputsRequest.ProtoReflect.Descriptor instead.
func (*RegisterResourceOutputsRequest) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{6}
2019-07-15 21:26:28 +00:00
}
func (x *RegisterResourceOutputsRequest) GetUrn() string {
if x != nil {
return x.Urn
2019-07-15 21:26:28 +00:00
}
return ""
}
func (x *RegisterResourceOutputsRequest) GetOutputs() *structpb.Struct {
if x != nil {
return x.Outputs
}
return nil
}
2020-02-28 11:53:47 +00:00
type ResourceInvokeRequest struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Pass provider checksums in requests and save to state (#13789) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This extends the resource monitor interface with fields for plugin checksums (on top of the existing plugin version and download url fields). These fields are threaded through the engine and are persisted in resource state. The sent or saved data is then used when installing plugins to ensure that the checksums match what was recorded at the time the SDK was built. Similar to https://github.com/pulumi/pulumi/pull/13776 nothing is using this yet, but this lays the engine side plumbing for them. ## Checklist - [ ] I have run `make tidy` to update any new dependencies - [ ] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-11 15:54:07 +00:00
Tok string `protobuf:"bytes,1,opt,name=tok,proto3" json:"tok,omitempty"` // the function token to invoke.
Args *structpb.Struct `protobuf:"bytes,2,opt,name=args,proto3" json:"args,omitempty"` // the arguments for the function invocation.
Provider string `protobuf:"bytes,3,opt,name=provider,proto3" json:"provider,omitempty"` // an optional reference to the provider version to use for this invoke.
Version string `protobuf:"bytes,4,opt,name=version,proto3" json:"version,omitempty"` // the version of the provider to use when servicing this request.
AcceptResources bool `protobuf:"varint,5,opt,name=acceptResources,proto3" json:"acceptResources,omitempty"` // when true operations should return resource references as strongly typed.
PluginDownloadURL string `protobuf:"bytes,6,opt,name=pluginDownloadURL,proto3" json:"pluginDownloadURL,omitempty"` // an optional reference to the provider url to use for this invoke.
PluginChecksums map[string][]byte `protobuf:"bytes,8,rep,name=pluginChecksums,proto3" json:"pluginChecksums,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"` // a map of checksums expected for the provider plugin.
SourcePosition *SourcePosition `protobuf:"bytes,7,opt,name=sourcePosition,proto3" json:"sourcePosition,omitempty"` // the optional source position of the user code that initiated the invoke.
}
func (x *ResourceInvokeRequest) Reset() {
*x = ResourceInvokeRequest{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[7]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *ResourceInvokeRequest) String() string {
return protoimpl.X.MessageStringOf(x)
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
func (*ResourceInvokeRequest) ProtoMessage() {}
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
func (x *ResourceInvokeRequest) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[7]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
return mi.MessageOf(x)
}
// Deprecated: Use ResourceInvokeRequest.ProtoReflect.Descriptor instead.
func (*ResourceInvokeRequest) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{7}
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
func (x *ResourceInvokeRequest) GetTok() string {
if x != nil {
return x.Tok
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
return ""
}
func (x *ResourceInvokeRequest) GetArgs() *structpb.Struct {
if x != nil {
return x.Args
}
return nil
}
func (x *ResourceInvokeRequest) GetProvider() string {
if x != nil {
return x.Provider
}
return ""
}
func (x *ResourceInvokeRequest) GetVersion() string {
if x != nil {
return x.Version
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
return ""
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
func (x *ResourceInvokeRequest) GetAcceptResources() bool {
if x != nil {
return x.AcceptResources
Initial support for remote component construction. (#5280) 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.
2020-09-08 02:33:55 +00:00
}
return false
Initial support for remote component construction. (#5280) 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.
2020-09-08 02:33:55 +00:00
}
func (x *ResourceInvokeRequest) GetPluginDownloadURL() string {
if x != nil {
return x.PluginDownloadURL
}
return ""
Initial support for remote component construction. (#5280) 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.
2020-09-08 02:33:55 +00:00
}
Pass provider checksums in requests and save to state (#13789) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This extends the resource monitor interface with fields for plugin checksums (on top of the existing plugin version and download url fields). These fields are threaded through the engine and are persisted in resource state. The sent or saved data is then used when installing plugins to ensure that the checksums match what was recorded at the time the SDK was built. Similar to https://github.com/pulumi/pulumi/pull/13776 nothing is using this yet, but this lays the engine side plumbing for them. ## Checklist - [ ] I have run `make tidy` to update any new dependencies - [ ] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-11 15:54:07 +00:00
func (x *ResourceInvokeRequest) GetPluginChecksums() map[string][]byte {
if x != nil {
return x.PluginChecksums
}
return nil
}
[engine] Add support for source positions These changes add support for passing source position information in gRPC metadata and recording the source position that corresponds to a resource registration in the statefile. Enabling source position information in the resource model can provide substantial benefits, including but not limited to: - Better errors from the Pulumi CLI - Go-to-defintion for resources in state - Editor integration for errors, etc. from `pulumi preview` Source positions are (file, line) or (file, line, column) tuples represented as URIs. The line and column are stored in the fragment portion of the URI as "line(,column)?". The scheme of the URI and the form of its path component depends on the context in which it is generated or used: - During an active update, the URI's scheme is `file` and paths are absolute filesystem paths. This allows consumers to easily access arbitrary files that are available on the host. - In a statefile, the URI's scheme is `project` and paths are relative to the project root. This allows consumers to resolve source positions relative to the project file in different contexts irrespective of the location of the project itself (e.g. given a project-relative path and the URL of the project's root on GitHub, one can build a GitHub URL for the source position). During an update, source position information may be attached to gRPC calls as "source-position" metadata. This allows arbitrary calls to be associated with source positions without changes to their protobuf payloads. Modifying the protobuf payloads is also a viable approach, but is somewhat more invasive than attaching metadata, and requires changes to every call signature. Source positions should reflect the position in user code that initiated a resource model operation (e.g. the source position passed with `RegisterResource` for `pet` in the example above should be the source position in `index.ts`, _not_ the source position in the Pulumi SDK). In general, the Pulumi SDK should be able to infer the source position of the resource registration, as the relationship between a resource registration and its corresponding user code should be static per SDK. Source positions in state files will be stored as a new `registeredAt` property on each resource. This property is optional.
2023-06-29 18:41:19 +00:00
func (x *ResourceInvokeRequest) GetSourcePosition() *SourcePosition {
if x != nil {
return x.SourcePosition
}
return nil
}
Split CallRequest into ResourceCallRequest (#15404) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> Similar to what we did to the `InvokeRequest` a while ago. We're currently using the same protobuf structure for `Provider.Call` and `ResourceMonitor.Call` despite different field sets being filled in for each of them. This splits the structure into `CallRequest` for providers and `ResourceCallRequest` for the resource monitor. A number of fields in each are removed and marked reserved with a comment explaining why. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-08 13:16:23 +00:00
type ResourceCallRequest struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Tok string `protobuf:"bytes,1,opt,name=tok,proto3" json:"tok,omitempty"` // the function token to invoke.
Args *structpb.Struct `protobuf:"bytes,2,opt,name=args,proto3" json:"args,omitempty"` // the arguments for the function invocation.
ArgDependencies map[string]*ResourceCallRequest_ArgumentDependencies `protobuf:"bytes,3,rep,name=argDependencies,proto3" json:"argDependencies,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"` // a map from argument keys to the dependencies of the argument.
Provider string `protobuf:"bytes,4,opt,name=provider,proto3" json:"provider,omitempty"` // an optional reference to the provider to use for this invoke.
Version string `protobuf:"bytes,5,opt,name=version,proto3" json:"version,omitempty"` // the version of the provider to use when servicing this request.
PluginDownloadURL string `protobuf:"bytes,13,opt,name=pluginDownloadURL,proto3" json:"pluginDownloadURL,omitempty"` // the pluginDownloadURL of the provider to use when servicing this request.
PluginChecksums map[string][]byte `protobuf:"bytes,16,rep,name=pluginChecksums,proto3" json:"pluginChecksums,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"` // a map of checksums of the provider to use when servicing this request.
SourcePosition *SourcePosition `protobuf:"bytes,15,opt,name=sourcePosition,proto3" json:"sourcePosition,omitempty"` // the optional source position of the user code that initiated the call.
}
func (x *ResourceCallRequest) Reset() {
*x = ResourceCallRequest{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[8]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *ResourceCallRequest) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*ResourceCallRequest) ProtoMessage() {}
func (x *ResourceCallRequest) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[8]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use ResourceCallRequest.ProtoReflect.Descriptor instead.
func (*ResourceCallRequest) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{8}
}
func (x *ResourceCallRequest) GetTok() string {
if x != nil {
return x.Tok
}
return ""
}
func (x *ResourceCallRequest) GetArgs() *structpb.Struct {
if x != nil {
return x.Args
}
return nil
}
func (x *ResourceCallRequest) GetArgDependencies() map[string]*ResourceCallRequest_ArgumentDependencies {
if x != nil {
return x.ArgDependencies
}
return nil
}
func (x *ResourceCallRequest) GetProvider() string {
if x != nil {
return x.Provider
}
return ""
}
func (x *ResourceCallRequest) GetVersion() string {
if x != nil {
return x.Version
}
return ""
}
func (x *ResourceCallRequest) GetPluginDownloadURL() string {
if x != nil {
return x.PluginDownloadURL
}
return ""
}
func (x *ResourceCallRequest) GetPluginChecksums() map[string][]byte {
if x != nil {
return x.PluginChecksums
}
return nil
}
func (x *ResourceCallRequest) GetSourcePosition() *SourcePosition {
if x != nil {
return x.SourcePosition
}
return nil
}
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
// TransformResourceOptions is a subset of all resource options that are relevant to transforms.
type TransformResourceOptions struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
DependsOn []string `protobuf:"bytes,1,rep,name=depends_on,json=dependsOn,proto3" json:"depends_on,omitempty"`
Protect bool `protobuf:"varint,2,opt,name=protect,proto3" json:"protect,omitempty"`
IgnoreChanges []string `protobuf:"bytes,3,rep,name=ignore_changes,json=ignoreChanges,proto3" json:"ignore_changes,omitempty"`
ReplaceOnChanges []string `protobuf:"bytes,4,rep,name=replace_on_changes,json=replaceOnChanges,proto3" json:"replace_on_changes,omitempty"`
Version string `protobuf:"bytes,5,opt,name=version,proto3" json:"version,omitempty"`
Aliases []*Alias `protobuf:"bytes,6,rep,name=aliases,proto3" json:"aliases,omitempty"`
Provider string `protobuf:"bytes,7,opt,name=provider,proto3" json:"provider,omitempty"`
CustomTimeouts *RegisterResourceRequest_CustomTimeouts `protobuf:"bytes,8,opt,name=custom_timeouts,json=customTimeouts,proto3" json:"custom_timeouts,omitempty"`
PluginDownloadUrl string `protobuf:"bytes,9,opt,name=plugin_download_url,json=pluginDownloadUrl,proto3" json:"plugin_download_url,omitempty"`
RetainOnDelete bool `protobuf:"varint,10,opt,name=retain_on_delete,json=retainOnDelete,proto3" json:"retain_on_delete,omitempty"`
DeletedWith string `protobuf:"bytes,11,opt,name=deleted_with,json=deletedWith,proto3" json:"deleted_with,omitempty"`
DeleteBeforeReplace *bool `protobuf:"varint,12,opt,name=delete_before_replace,json=deleteBeforeReplace,proto3,oneof" json:"delete_before_replace,omitempty"`
AdditionalSecretOutputs []string `protobuf:"bytes,13,rep,name=additional_secret_outputs,json=additionalSecretOutputs,proto3" json:"additional_secret_outputs,omitempty"`
Providers map[string]string `protobuf:"bytes,14,rep,name=providers,proto3" json:"providers,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"`
PluginChecksums map[string][]byte `protobuf:"bytes,15,rep,name=plugin_checksums,json=pluginChecksums,proto3" json:"plugin_checksums,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"`
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
CreateIfNotExists string `protobuf:"bytes,16,opt,name=create_if_not_exists,json=createIfNotExists,proto3" json:"create_if_not_exists,omitempty"`
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
}
func (x *TransformResourceOptions) Reset() {
*x = TransformResourceOptions{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[9]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *TransformResourceOptions) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*TransformResourceOptions) ProtoMessage() {}
func (x *TransformResourceOptions) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[9]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use TransformResourceOptions.ProtoReflect.Descriptor instead.
func (*TransformResourceOptions) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{9}
}
func (x *TransformResourceOptions) GetDependsOn() []string {
if x != nil {
return x.DependsOn
}
return nil
}
func (x *TransformResourceOptions) GetProtect() bool {
if x != nil {
return x.Protect
}
return false
}
func (x *TransformResourceOptions) GetIgnoreChanges() []string {
if x != nil {
return x.IgnoreChanges
}
return nil
}
func (x *TransformResourceOptions) GetReplaceOnChanges() []string {
if x != nil {
return x.ReplaceOnChanges
}
return nil
}
func (x *TransformResourceOptions) GetVersion() string {
if x != nil {
return x.Version
}
return ""
}
func (x *TransformResourceOptions) GetAliases() []*Alias {
if x != nil {
return x.Aliases
}
return nil
}
func (x *TransformResourceOptions) GetProvider() string {
if x != nil {
return x.Provider
}
return ""
}
func (x *TransformResourceOptions) GetCustomTimeouts() *RegisterResourceRequest_CustomTimeouts {
if x != nil {
return x.CustomTimeouts
}
return nil
}
func (x *TransformResourceOptions) GetPluginDownloadUrl() string {
if x != nil {
return x.PluginDownloadUrl
}
return ""
}
func (x *TransformResourceOptions) GetRetainOnDelete() bool {
if x != nil {
return x.RetainOnDelete
}
return false
}
func (x *TransformResourceOptions) GetDeletedWith() string {
if x != nil {
return x.DeletedWith
}
return ""
}
func (x *TransformResourceOptions) GetDeleteBeforeReplace() bool {
if x != nil && x.DeleteBeforeReplace != nil {
return *x.DeleteBeforeReplace
}
return false
}
func (x *TransformResourceOptions) GetAdditionalSecretOutputs() []string {
if x != nil {
return x.AdditionalSecretOutputs
}
return nil
}
func (x *TransformResourceOptions) GetProviders() map[string]string {
if x != nil {
return x.Providers
}
return nil
}
func (x *TransformResourceOptions) GetPluginChecksums() map[string][]byte {
if x != nil {
return x.PluginChecksums
}
return nil
}
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
func (x *TransformResourceOptions) GetCreateIfNotExists() string {
if x != nil {
return x.CreateIfNotExists
}
return ""
}
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
type TransformRequest struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Type string `protobuf:"bytes,1,opt,name=type,proto3" json:"type,omitempty"` // the type of the resource.
Name string `protobuf:"bytes,2,opt,name=name,proto3" json:"name,omitempty"` // the name of the resource.
Custom bool `protobuf:"varint,3,opt,name=custom,proto3" json:"custom,omitempty"` // true if the resource is a custom resource, else it's a component resource.
Parent string `protobuf:"bytes,4,opt,name=parent,proto3" json:"parent,omitempty"` // the parent of the resource, this can't be changed by the transform.
Properties *structpb.Struct `protobuf:"bytes,5,opt,name=properties,proto3" json:"properties,omitempty"` // the input properties of the resource.
Options *TransformResourceOptions `protobuf:"bytes,6,opt,name=options,proto3" json:"options,omitempty"` // the options for the resource.
}
func (x *TransformRequest) Reset() {
*x = TransformRequest{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[10]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *TransformRequest) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*TransformRequest) ProtoMessage() {}
func (x *TransformRequest) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[10]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use TransformRequest.ProtoReflect.Descriptor instead.
func (*TransformRequest) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{10}
}
func (x *TransformRequest) GetType() string {
if x != nil {
return x.Type
}
return ""
}
func (x *TransformRequest) GetName() string {
if x != nil {
return x.Name
}
return ""
}
func (x *TransformRequest) GetCustom() bool {
if x != nil {
return x.Custom
}
return false
}
func (x *TransformRequest) GetParent() string {
if x != nil {
return x.Parent
}
return ""
}
func (x *TransformRequest) GetProperties() *structpb.Struct {
if x != nil {
return x.Properties
}
return nil
}
func (x *TransformRequest) GetOptions() *TransformResourceOptions {
if x != nil {
return x.Options
}
return nil
}
type TransformResponse struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Properties *structpb.Struct `protobuf:"bytes,1,opt,name=properties,proto3" json:"properties,omitempty"` // the transformed input properties.
Options *TransformResourceOptions `protobuf:"bytes,2,opt,name=options,proto3" json:"options,omitempty"` // the options for the resource.
}
func (x *TransformResponse) Reset() {
*x = TransformResponse{}
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[11]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *TransformResponse) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*TransformResponse) ProtoMessage() {}
func (x *TransformResponse) ProtoReflect() protoreflect.Message {
mi := &file_pulumi_resource_proto_msgTypes[11]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use TransformResponse.ProtoReflect.Descriptor instead.
func (*TransformResponse) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{11}
}
func (x *TransformResponse) GetProperties() *structpb.Struct {
if x != nil {
return x.Properties
}
return nil
}
func (x *TransformResponse) GetOptions() *TransformResourceOptions {
if x != nil {
return x.Options
}
return nil
}
type RegisterPackageRequest struct {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Name string `protobuf:"bytes,1,opt,name=name,proto3" json:"name,omitempty"`
Version string `protobuf:"bytes,2,opt,name=version,proto3" json:"version,omitempty"`
PluginDownloadUrl string `protobuf:"bytes,3,opt,name=plugin_download_url,json=pluginDownloadUrl,proto3" json:"plugin_download_url,omitempty"`
PluginChecksums map[string][]byte `protobuf:"bytes,4,rep,name=plugin_checksums,json=pluginChecksums,proto3" json:"plugin_checksums,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"`
Parameter *PackageParameter `protobuf:"bytes,5,opt,name=parameter,proto3" json:"parameter,omitempty"`
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
}
func (x *RegisterPackageRequest) Reset() {
*x = RegisterPackageRequest{}
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[12]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *RegisterPackageRequest) String() string {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
return protoimpl.X.MessageStringOf(x)
}
func (*RegisterPackageRequest) ProtoMessage() {}
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
func (x *RegisterPackageRequest) ProtoReflect() protoreflect.Message {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
mi := &file_pulumi_resource_proto_msgTypes[12]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use RegisterPackageRequest.ProtoReflect.Descriptor instead.
func (*RegisterPackageRequest) Descriptor() ([]byte, []int) {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
return file_pulumi_resource_proto_rawDescGZIP(), []int{12}
}
func (x *RegisterPackageRequest) GetName() string {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
if x != nil {
return x.Name
}
return ""
}
func (x *RegisterPackageRequest) GetVersion() string {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
if x != nil {
return x.Version
}
return ""
}
func (x *RegisterPackageRequest) GetPluginDownloadUrl() string {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
if x != nil {
return x.PluginDownloadUrl
}
return ""
}
func (x *RegisterPackageRequest) GetPluginChecksums() map[string][]byte {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
if x != nil {
return x.PluginChecksums
}
return nil
}
func (x *RegisterPackageRequest) GetParameter() *PackageParameter {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
if x != nil {
return x.Parameter
}
return nil
}
type RegisterPackageResponse struct {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
// The UUID package reference for this registered package.
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
Ref string `protobuf:"bytes,1,opt,name=ref,proto3" json:"ref,omitempty"`
}
func (x *RegisterPackageResponse) Reset() {
*x = RegisterPackageResponse{}
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[13]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *RegisterPackageResponse) String() string {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
return protoimpl.X.MessageStringOf(x)
}
func (*RegisterPackageResponse) ProtoMessage() {}
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
func (x *RegisterPackageResponse) ProtoReflect() protoreflect.Message {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
mi := &file_pulumi_resource_proto_msgTypes[13]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use RegisterPackageResponse.ProtoReflect.Descriptor instead.
func (*RegisterPackageResponse) Descriptor() ([]byte, []int) {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
return file_pulumi_resource_proto_rawDescGZIP(), []int{13}
}
func (x *RegisterPackageResponse) GetRef() string {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
if x != nil {
return x.Ref
}
return ""
}
type PackageParameter struct {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Name string `protobuf:"bytes,1,opt,name=name,proto3" json:"name,omitempty"`
Version string `protobuf:"bytes,2,opt,name=version,proto3" json:"version,omitempty"`
Value *structpb.Value `protobuf:"bytes,3,opt,name=value,proto3" json:"value,omitempty"`
}
func (x *PackageParameter) Reset() {
*x = PackageParameter{}
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
if protoimpl.UnsafeEnabled {
mi := &file_pulumi_resource_proto_msgTypes[14]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *PackageParameter) String() string {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
return protoimpl.X.MessageStringOf(x)
}
func (*PackageParameter) ProtoMessage() {}
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
func (x *PackageParameter) ProtoReflect() protoreflect.Message {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
mi := &file_pulumi_resource_proto_msgTypes[14]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use PackageParameter.ProtoReflect.Descriptor instead.
func (*PackageParameter) Descriptor() ([]byte, []int) {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
return file_pulumi_resource_proto_rawDescGZIP(), []int{14}
}
func (x *PackageParameter) GetName() string {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
if x != nil {
return x.Name
}
return ""
}
func (x *PackageParameter) GetVersion() string {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
if x != nil {
return x.Version
}
return ""
}
func (x *PackageParameter) GetValue() *structpb.Value {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
if x != nil {
return x.Value
}
return nil
}
// PropertyDependencies describes the resources that a particular property depends on.
type RegisterResourceRequest_PropertyDependencies struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Initial support for remote component construction. (#5280) 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.
2020-09-08 02:33:55 +00:00
Urns []string `protobuf:"bytes,1,rep,name=urns,proto3" json:"urns,omitempty"` // A list of URNs this property depends on.
Initial support for remote component construction. (#5280) 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.
2020-09-08 02:33:55 +00:00
}
func (x *RegisterResourceRequest_PropertyDependencies) Reset() {
*x = RegisterResourceRequest_PropertyDependencies{}
if protoimpl.UnsafeEnabled {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
mi := &file_pulumi_resource_proto_msgTypes[16]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
Initial support for remote component construction. (#5280) 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.
2020-09-08 02:33:55 +00:00
}
}
func (x *RegisterResourceRequest_PropertyDependencies) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*RegisterResourceRequest_PropertyDependencies) ProtoMessage() {}
2020-02-28 11:53:47 +00:00
func (x *RegisterResourceRequest_PropertyDependencies) ProtoReflect() protoreflect.Message {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
mi := &file_pulumi_resource_proto_msgTypes[16]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use RegisterResourceRequest_PropertyDependencies.ProtoReflect.Descriptor instead.
func (*RegisterResourceRequest_PropertyDependencies) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{4, 0}
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
func (x *RegisterResourceRequest_PropertyDependencies) GetUrns() []string {
if x != nil {
return x.Urns
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
return nil
}
// CustomTimeouts allows a user to be able to create a set of custom timeout parameters.
type RegisterResourceRequest_CustomTimeouts struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Create string `protobuf:"bytes,1,opt,name=create,proto3" json:"create,omitempty"` // The create resource timeout represented as a string e.g. 5m.
Update string `protobuf:"bytes,2,opt,name=update,proto3" json:"update,omitempty"` // The update resource timeout represented as a string e.g. 5m.
Delete string `protobuf:"bytes,3,opt,name=delete,proto3" json:"delete,omitempty"` // The delete resource timeout represented as a string e.g. 5m.
}
func (x *RegisterResourceRequest_CustomTimeouts) Reset() {
*x = RegisterResourceRequest_CustomTimeouts{}
if protoimpl.UnsafeEnabled {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
mi := &file_pulumi_resource_proto_msgTypes[17]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *RegisterResourceRequest_CustomTimeouts) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*RegisterResourceRequest_CustomTimeouts) ProtoMessage() {}
func (x *RegisterResourceRequest_CustomTimeouts) ProtoReflect() protoreflect.Message {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
mi := &file_pulumi_resource_proto_msgTypes[17]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use RegisterResourceRequest_CustomTimeouts.ProtoReflect.Descriptor instead.
func (*RegisterResourceRequest_CustomTimeouts) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{4, 1}
}
func (x *RegisterResourceRequest_CustomTimeouts) GetCreate() string {
if x != nil {
return x.Create
}
return ""
}
func (x *RegisterResourceRequest_CustomTimeouts) GetUpdate() string {
if x != nil {
return x.Update
}
return ""
}
func (x *RegisterResourceRequest_CustomTimeouts) GetDelete() string {
if x != nil {
return x.Delete
}
return ""
}
// PropertyDependencies describes the resources that a particular property depends on.
type RegisterResourceResponse_PropertyDependencies struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Urns []string `protobuf:"bytes,1,rep,name=urns,proto3" json:"urns,omitempty"` // A list of URNs this property depends on.
}
func (x *RegisterResourceResponse_PropertyDependencies) Reset() {
*x = RegisterResourceResponse_PropertyDependencies{}
if protoimpl.UnsafeEnabled {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
mi := &file_pulumi_resource_proto_msgTypes[21]
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *RegisterResourceResponse_PropertyDependencies) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*RegisterResourceResponse_PropertyDependencies) ProtoMessage() {}
func (x *RegisterResourceResponse_PropertyDependencies) ProtoReflect() protoreflect.Message {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
mi := &file_pulumi_resource_proto_msgTypes[21]
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use RegisterResourceResponse_PropertyDependencies.ProtoReflect.Descriptor instead.
func (*RegisterResourceResponse_PropertyDependencies) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{5, 0}
}
func (x *RegisterResourceResponse_PropertyDependencies) GetUrns() []string {
if x != nil {
return x.Urns
}
return nil
}
Split CallRequest into ResourceCallRequest (#15404) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> Similar to what we did to the `InvokeRequest` a while ago. We're currently using the same protobuf structure for `Provider.Call` and `ResourceMonitor.Call` despite different field sets being filled in for each of them. This splits the structure into `CallRequest` for providers and `ResourceCallRequest` for the resource monitor. A number of fields in each are removed and marked reserved with a comment explaining why. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-08 13:16:23 +00:00
// ArgumentDependencies describes the resources that a particular argument depends on.
type ResourceCallRequest_ArgumentDependencies struct {
state protoimpl.MessageState
sizeCache protoimpl.SizeCache
unknownFields protoimpl.UnknownFields
Urns []string `protobuf:"bytes,1,rep,name=urns,proto3" json:"urns,omitempty"` // A list of URNs this argument depends on.
}
func (x *ResourceCallRequest_ArgumentDependencies) Reset() {
*x = ResourceCallRequest_ArgumentDependencies{}
if protoimpl.UnsafeEnabled {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
mi := &file_pulumi_resource_proto_msgTypes[24]
Split CallRequest into ResourceCallRequest (#15404) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> Similar to what we did to the `InvokeRequest` a while ago. We're currently using the same protobuf structure for `Provider.Call` and `ResourceMonitor.Call` despite different field sets being filled in for each of them. This splits the structure into `CallRequest` for providers and `ResourceCallRequest` for the resource monitor. A number of fields in each are removed and marked reserved with a comment explaining why. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-08 13:16:23 +00:00
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
ms.StoreMessageInfo(mi)
}
}
func (x *ResourceCallRequest_ArgumentDependencies) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*ResourceCallRequest_ArgumentDependencies) ProtoMessage() {}
func (x *ResourceCallRequest_ArgumentDependencies) ProtoReflect() protoreflect.Message {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
mi := &file_pulumi_resource_proto_msgTypes[24]
Split CallRequest into ResourceCallRequest (#15404) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> Similar to what we did to the `InvokeRequest` a while ago. We're currently using the same protobuf structure for `Provider.Call` and `ResourceMonitor.Call` despite different field sets being filled in for each of them. This splits the structure into `CallRequest` for providers and `ResourceCallRequest` for the resource monitor. A number of fields in each are removed and marked reserved with a comment explaining why. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-08 13:16:23 +00:00
if protoimpl.UnsafeEnabled && x != nil {
ms := protoimpl.X.MessageStateOf(protoimpl.Pointer(x))
if ms.LoadMessageInfo() == nil {
ms.StoreMessageInfo(mi)
}
return ms
}
return mi.MessageOf(x)
}
// Deprecated: Use ResourceCallRequest_ArgumentDependencies.ProtoReflect.Descriptor instead.
func (*ResourceCallRequest_ArgumentDependencies) Descriptor() ([]byte, []int) {
return file_pulumi_resource_proto_rawDescGZIP(), []int{8, 0}
}
func (x *ResourceCallRequest_ArgumentDependencies) GetUrns() []string {
if x != nil {
return x.Urns
}
return nil
}
var File_pulumi_resource_proto protoreflect.FileDescriptor
var file_pulumi_resource_proto_rawDesc = []byte{
0x0a, 0x15, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x2f, 0x72, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63,
0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x12, 0x09, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72,
0x70, 0x63, 0x1a, 0x1b, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2f, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x62, 0x75, 0x66, 0x2f, 0x65, 0x6d, 0x70, 0x74, 0x79, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x1a,
0x1c, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75, 0x66,
0x2f, 0x73, 0x74, 0x72, 0x75, 0x63, 0x74, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x1a, 0x15, 0x70,
0x75, 0x6c, 0x75, 0x6d, 0x69, 0x2f, 0x70, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72, 0x2e, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x1a, 0x12, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x2f, 0x61, 0x6c, 0x69,
[engine] Add support for source positions These changes add support for passing source position information in gRPC metadata and recording the source position that corresponds to a resource registration in the statefile. Enabling source position information in the resource model can provide substantial benefits, including but not limited to: - Better errors from the Pulumi CLI - Go-to-defintion for resources in state - Editor integration for errors, etc. from `pulumi preview` Source positions are (file, line) or (file, line, column) tuples represented as URIs. The line and column are stored in the fragment portion of the URI as "line(,column)?". The scheme of the URI and the form of its path component depends on the context in which it is generated or used: - During an active update, the URI's scheme is `file` and paths are absolute filesystem paths. This allows consumers to easily access arbitrary files that are available on the host. - In a statefile, the URI's scheme is `project` and paths are relative to the project root. This allows consumers to resolve source positions relative to the project file in different contexts irrespective of the location of the project itself (e.g. given a project-relative path and the URL of the project's root on GitHub, one can build a GitHub URL for the source position). During an update, source position information may be attached to gRPC calls as "source-position" metadata. This allows arbitrary calls to be associated with source positions without changes to their protobuf payloads. Modifying the protobuf payloads is also a viable approach, but is somewhat more invasive than attaching metadata, and requires changes to every call signature. Source positions should reflect the position in user code that initiated a resource model operation (e.g. the source position passed with `RegisterResource` for `pet` in the example above should be the source position in `index.ts`, _not_ the source position in the Pulumi SDK). In general, the Pulumi SDK should be able to infer the source position of the resource registration, as the relationship between a resource registration and its corresponding user code should be static per SDK. Source positions in state files will be stored as a new `registeredAt` property on each resource. This property is optional.
2023-06-29 18:41:19 +00:00
0x61, 0x73, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x1a, 0x13, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69,
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
0x2f, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x1a, 0x15, 0x70,
0x75, 0x6c, 0x75, 0x6d, 0x69, 0x2f, 0x63, 0x61, 0x6c, 0x6c, 0x62, 0x61, 0x63, 0x6b, 0x2e, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x22, 0x28, 0x0a, 0x16, 0x53, 0x75, 0x70, 0x70, 0x6f, 0x72, 0x74, 0x73,
0x46, 0x65, 0x61, 0x74, 0x75, 0x72, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x12, 0x0e,
0x0a, 0x02, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x02, 0x69, 0x64, 0x22, 0x39,
0x0a, 0x17, 0x53, 0x75, 0x70, 0x70, 0x6f, 0x72, 0x74, 0x73, 0x46, 0x65, 0x61, 0x74, 0x75, 0x72,
0x65, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x12, 0x1e, 0x0a, 0x0a, 0x68, 0x61, 0x73,
0x53, 0x75, 0x70, 0x70, 0x6f, 0x72, 0x74, 0x18, 0x01, 0x20, 0x01, 0x28, 0x08, 0x52, 0x0a, 0x68,
0x61, 0x73, 0x53, 0x75, 0x70, 0x70, 0x6f, 0x72, 0x74, 0x22, 0xa5, 0x05, 0x0a, 0x13, 0x52, 0x65,
0x61, 0x64, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73,
0x74, 0x12, 0x0e, 0x0a, 0x02, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x02, 0x69,
0x64, 0x12, 0x12, 0x0a, 0x04, 0x74, 0x79, 0x70, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52,
0x04, 0x74, 0x79, 0x70, 0x65, 0x12, 0x12, 0x0a, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x18, 0x03, 0x20,
0x01, 0x28, 0x09, 0x52, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x12, 0x16, 0x0a, 0x06, 0x70, 0x61, 0x72,
0x65, 0x6e, 0x74, 0x18, 0x04, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x70, 0x61, 0x72, 0x65, 0x6e,
0x74, 0x12, 0x37, 0x0a, 0x0a, 0x70, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x69, 0x65, 0x73, 0x18,
0x05, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x17, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75, 0x66, 0x2e, 0x53, 0x74, 0x72, 0x75, 0x63, 0x74, 0x52, 0x0a,
0x70, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x69, 0x65, 0x73, 0x12, 0x22, 0x0a, 0x0c, 0x64, 0x65,
0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x18, 0x06, 0x20, 0x03, 0x28, 0x09,
0x52, 0x0c, 0x64, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x12, 0x1a,
0x0a, 0x08, 0x70, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72, 0x18, 0x07, 0x20, 0x01, 0x28, 0x09,
0x52, 0x08, 0x70, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72, 0x12, 0x18, 0x0a, 0x07, 0x76, 0x65,
0x72, 0x73, 0x69, 0x6f, 0x6e, 0x18, 0x08, 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x76, 0x65, 0x72,
0x73, 0x69, 0x6f, 0x6e, 0x12, 0x24, 0x0a, 0x0d, 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x53, 0x65,
0x63, 0x72, 0x65, 0x74, 0x73, 0x18, 0x09, 0x20, 0x01, 0x28, 0x08, 0x52, 0x0d, 0x61, 0x63, 0x63,
0x65, 0x70, 0x74, 0x53, 0x65, 0x63, 0x72, 0x65, 0x74, 0x73, 0x12, 0x38, 0x0a, 0x17, 0x61, 0x64,
0x64, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x53, 0x65, 0x63, 0x72, 0x65, 0x74, 0x4f, 0x75,
0x74, 0x70, 0x75, 0x74, 0x73, 0x18, 0x0a, 0x20, 0x03, 0x28, 0x09, 0x52, 0x17, 0x61, 0x64, 0x64,
0x69, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x53, 0x65, 0x63, 0x72, 0x65, 0x74, 0x4f, 0x75, 0x74,
0x70, 0x75, 0x74, 0x73, 0x12, 0x28, 0x0a, 0x0f, 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x52, 0x65,
0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x73, 0x18, 0x0c, 0x20, 0x01, 0x28, 0x08, 0x52, 0x0f, 0x61,
0x63, 0x63, 0x65, 0x70, 0x74, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x73, 0x12, 0x2c,
0x0a, 0x11, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x44, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64,
0x55, 0x52, 0x4c, 0x18, 0x0d, 0x20, 0x01, 0x28, 0x09, 0x52, 0x11, 0x70, 0x6c, 0x75, 0x67, 0x69,
0x6e, 0x44, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x55, 0x52, 0x4c, 0x12, 0x5d, 0x0a, 0x0f,
0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x18,
0x0f, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x33, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70,
0x63, 0x2e, 0x52, 0x65, 0x61, 0x64, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65,
0x71, 0x75, 0x65, 0x73, 0x74, 0x2e, 0x50, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63,
0x6b, 0x73, 0x75, 0x6d, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x52, 0x0f, 0x70, 0x6c, 0x75, 0x67,
0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x12, 0x41, 0x0a, 0x0e, 0x73,
0x6f, 0x75, 0x72, 0x63, 0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x18, 0x0e, 0x20,
0x01, 0x28, 0x0b, 0x32, 0x19, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e,
0x53, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x52, 0x0e,
0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x1a, 0x42,
0x0a, 0x14, 0x50, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d,
0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03, 0x6b, 0x65, 0x79, 0x18, 0x01, 0x20,
0x01, 0x28, 0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x14, 0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75,
0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0c, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x3a, 0x02,
0x38, 0x01, 0x4a, 0x04, 0x08, 0x0b, 0x10, 0x0c, 0x52, 0x07, 0x61, 0x6c, 0x69, 0x61, 0x73, 0x65,
0x73, 0x22, 0x61, 0x0a, 0x14, 0x52, 0x65, 0x61, 0x64, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63,
0x65, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x12, 0x10, 0x0a, 0x03, 0x75, 0x72, 0x6e,
0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x75, 0x72, 0x6e, 0x12, 0x37, 0x0a, 0x0a, 0x70,
0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x69, 0x65, 0x73, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32,
0x17, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75,
0x66, 0x2e, 0x53, 0x74, 0x72, 0x75, 0x63, 0x74, 0x52, 0x0a, 0x70, 0x72, 0x6f, 0x70, 0x65, 0x72,
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
0x74, 0x69, 0x65, 0x73, 0x22, 0xb6, 0x0f, 0x0a, 0x17, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65,
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
0x72, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74,
0x12, 0x12, 0x0a, 0x04, 0x74, 0x79, 0x70, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x04,
0x74, 0x79, 0x70, 0x65, 0x12, 0x12, 0x0a, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x18, 0x02, 0x20, 0x01,
0x28, 0x09, 0x52, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x12, 0x16, 0x0a, 0x06, 0x70, 0x61, 0x72, 0x65,
0x6e, 0x74, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x70, 0x61, 0x72, 0x65, 0x6e, 0x74,
0x12, 0x16, 0x0a, 0x06, 0x63, 0x75, 0x73, 0x74, 0x6f, 0x6d, 0x18, 0x04, 0x20, 0x01, 0x28, 0x08,
0x52, 0x06, 0x63, 0x75, 0x73, 0x74, 0x6f, 0x6d, 0x12, 0x2f, 0x0a, 0x06, 0x6f, 0x62, 0x6a, 0x65,
0x63, 0x74, 0x18, 0x05, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x17, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c,
0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75, 0x66, 0x2e, 0x53, 0x74, 0x72, 0x75, 0x63,
0x74, 0x52, 0x06, 0x6f, 0x62, 0x6a, 0x65, 0x63, 0x74, 0x12, 0x18, 0x0a, 0x07, 0x70, 0x72, 0x6f,
0x74, 0x65, 0x63, 0x74, 0x18, 0x06, 0x20, 0x01, 0x28, 0x08, 0x52, 0x07, 0x70, 0x72, 0x6f, 0x74,
0x65, 0x63, 0x74, 0x12, 0x22, 0x0a, 0x0c, 0x64, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63,
0x69, 0x65, 0x73, 0x18, 0x07, 0x20, 0x03, 0x28, 0x09, 0x52, 0x0c, 0x64, 0x65, 0x70, 0x65, 0x6e,
[engine] Add support for source positions These changes add support for passing source position information in gRPC metadata and recording the source position that corresponds to a resource registration in the statefile. Enabling source position information in the resource model can provide substantial benefits, including but not limited to: - Better errors from the Pulumi CLI - Go-to-defintion for resources in state - Editor integration for errors, etc. from `pulumi preview` Source positions are (file, line) or (file, line, column) tuples represented as URIs. The line and column are stored in the fragment portion of the URI as "line(,column)?". The scheme of the URI and the form of its path component depends on the context in which it is generated or used: - During an active update, the URI's scheme is `file` and paths are absolute filesystem paths. This allows consumers to easily access arbitrary files that are available on the host. - In a statefile, the URI's scheme is `project` and paths are relative to the project root. This allows consumers to resolve source positions relative to the project file in different contexts irrespective of the location of the project itself (e.g. given a project-relative path and the URL of the project's root on GitHub, one can build a GitHub URL for the source position). During an update, source position information may be attached to gRPC calls as "source-position" metadata. This allows arbitrary calls to be associated with source positions without changes to their protobuf payloads. Modifying the protobuf payloads is also a viable approach, but is somewhat more invasive than attaching metadata, and requires changes to every call signature. Source positions should reflect the position in user code that initiated a resource model operation (e.g. the source position passed with `RegisterResource` for `pet` in the example above should be the source position in `index.ts`, _not_ the source position in the Pulumi SDK). In general, the Pulumi SDK should be able to infer the source position of the resource registration, as the relationship between a resource registration and its corresponding user code should be static per SDK. Source positions in state files will be stored as a new `registeredAt` property on each resource. This property is optional.
2023-06-29 18:41:19 +00:00
0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x12, 0x1a, 0x0a, 0x08, 0x70, 0x72, 0x6f, 0x76, 0x69,
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
0x64, 0x65, 0x72, 0x18, 0x08, 0x20, 0x01, 0x28, 0x09, 0x52, 0x08, 0x70, 0x72, 0x6f, 0x76, 0x69,
0x64, 0x65, 0x72, 0x12, 0x70, 0x0a, 0x14, 0x70, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x79, 0x44,
0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x18, 0x09, 0x20, 0x03, 0x28,
0x0b, 0x32, 0x3c, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65,
0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65,
0x71, 0x75, 0x65, 0x73, 0x74, 0x2e, 0x50, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x79, 0x44, 0x65,
0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x52,
0x14, 0x70, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x79, 0x44, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65,
0x6e, 0x63, 0x69, 0x65, 0x73, 0x12, 0x30, 0x0a, 0x13, 0x64, 0x65, 0x6c, 0x65, 0x74, 0x65, 0x42,
0x65, 0x66, 0x6f, 0x72, 0x65, 0x52, 0x65, 0x70, 0x6c, 0x61, 0x63, 0x65, 0x18, 0x0a, 0x20, 0x01,
0x28, 0x08, 0x52, 0x13, 0x64, 0x65, 0x6c, 0x65, 0x74, 0x65, 0x42, 0x65, 0x66, 0x6f, 0x72, 0x65,
0x52, 0x65, 0x70, 0x6c, 0x61, 0x63, 0x65, 0x12, 0x18, 0x0a, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69,
0x6f, 0x6e, 0x18, 0x0b, 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f,
0x6e, 0x12, 0x24, 0x0a, 0x0d, 0x69, 0x67, 0x6e, 0x6f, 0x72, 0x65, 0x43, 0x68, 0x61, 0x6e, 0x67,
0x65, 0x73, 0x18, 0x0c, 0x20, 0x03, 0x28, 0x09, 0x52, 0x0d, 0x69, 0x67, 0x6e, 0x6f, 0x72, 0x65,
0x43, 0x68, 0x61, 0x6e, 0x67, 0x65, 0x73, 0x12, 0x24, 0x0a, 0x0d, 0x61, 0x63, 0x63, 0x65, 0x70,
0x74, 0x53, 0x65, 0x63, 0x72, 0x65, 0x74, 0x73, 0x18, 0x0d, 0x20, 0x01, 0x28, 0x08, 0x52, 0x0d,
0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x53, 0x65, 0x63, 0x72, 0x65, 0x74, 0x73, 0x12, 0x38, 0x0a,
0x17, 0x61, 0x64, 0x64, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x53, 0x65, 0x63, 0x72, 0x65,
0x74, 0x4f, 0x75, 0x74, 0x70, 0x75, 0x74, 0x73, 0x18, 0x0e, 0x20, 0x03, 0x28, 0x09, 0x52, 0x17,
0x61, 0x64, 0x64, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x53, 0x65, 0x63, 0x72, 0x65, 0x74,
0x4f, 0x75, 0x74, 0x70, 0x75, 0x74, 0x73, 0x12, 0x1c, 0x0a, 0x09, 0x61, 0x6c, 0x69, 0x61, 0x73,
0x55, 0x52, 0x4e, 0x73, 0x18, 0x0f, 0x20, 0x03, 0x28, 0x09, 0x52, 0x09, 0x61, 0x6c, 0x69, 0x61,
0x73, 0x55, 0x52, 0x4e, 0x73, 0x12, 0x1a, 0x0a, 0x08, 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x49,
0x64, 0x18, 0x10, 0x20, 0x01, 0x28, 0x09, 0x52, 0x08, 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x49,
0x64, 0x12, 0x59, 0x0a, 0x0e, 0x63, 0x75, 0x73, 0x74, 0x6f, 0x6d, 0x54, 0x69, 0x6d, 0x65, 0x6f,
0x75, 0x74, 0x73, 0x18, 0x11, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x31, 0x2e, 0x70, 0x75, 0x6c, 0x75,
0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65,
0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x2e, 0x43, 0x75,
0x73, 0x74, 0x6f, 0x6d, 0x54, 0x69, 0x6d, 0x65, 0x6f, 0x75, 0x74, 0x73, 0x52, 0x0e, 0x63, 0x75,
0x73, 0x74, 0x6f, 0x6d, 0x54, 0x69, 0x6d, 0x65, 0x6f, 0x75, 0x74, 0x73, 0x12, 0x3e, 0x0a, 0x1a,
0x64, 0x65, 0x6c, 0x65, 0x74, 0x65, 0x42, 0x65, 0x66, 0x6f, 0x72, 0x65, 0x52, 0x65, 0x70, 0x6c,
0x61, 0x63, 0x65, 0x44, 0x65, 0x66, 0x69, 0x6e, 0x65, 0x64, 0x18, 0x12, 0x20, 0x01, 0x28, 0x08,
0x52, 0x1a, 0x64, 0x65, 0x6c, 0x65, 0x74, 0x65, 0x42, 0x65, 0x66, 0x6f, 0x72, 0x65, 0x52, 0x65,
0x70, 0x6c, 0x61, 0x63, 0x65, 0x44, 0x65, 0x66, 0x69, 0x6e, 0x65, 0x64, 0x12, 0x34, 0x0a, 0x15,
0x73, 0x75, 0x70, 0x70, 0x6f, 0x72, 0x74, 0x73, 0x50, 0x61, 0x72, 0x74, 0x69, 0x61, 0x6c, 0x56,
0x61, 0x6c, 0x75, 0x65, 0x73, 0x18, 0x13, 0x20, 0x01, 0x28, 0x08, 0x52, 0x15, 0x73, 0x75, 0x70,
0x70, 0x6f, 0x72, 0x74, 0x73, 0x50, 0x61, 0x72, 0x74, 0x69, 0x61, 0x6c, 0x56, 0x61, 0x6c, 0x75,
0x65, 0x73, 0x12, 0x16, 0x0a, 0x06, 0x72, 0x65, 0x6d, 0x6f, 0x74, 0x65, 0x18, 0x14, 0x20, 0x01,
0x28, 0x08, 0x52, 0x06, 0x72, 0x65, 0x6d, 0x6f, 0x74, 0x65, 0x12, 0x28, 0x0a, 0x0f, 0x61, 0x63,
0x63, 0x65, 0x70, 0x74, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x73, 0x18, 0x15, 0x20,
0x01, 0x28, 0x08, 0x52, 0x0f, 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x52, 0x65, 0x73, 0x6f, 0x75,
0x72, 0x63, 0x65, 0x73, 0x12, 0x4f, 0x0a, 0x09, 0x70, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72,
0x73, 0x18, 0x16, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x31, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69,
0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65, 0x73, 0x6f,
0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x2e, 0x50, 0x72, 0x6f, 0x76,
0x69, 0x64, 0x65, 0x72, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x52, 0x09, 0x70, 0x72, 0x6f, 0x76,
0x69, 0x64, 0x65, 0x72, 0x73, 0x12, 0x2a, 0x0a, 0x10, 0x72, 0x65, 0x70, 0x6c, 0x61, 0x63, 0x65,
0x4f, 0x6e, 0x43, 0x68, 0x61, 0x6e, 0x67, 0x65, 0x73, 0x18, 0x17, 0x20, 0x03, 0x28, 0x09, 0x52,
0x10, 0x72, 0x65, 0x70, 0x6c, 0x61, 0x63, 0x65, 0x4f, 0x6e, 0x43, 0x68, 0x61, 0x6e, 0x67, 0x65,
0x73, 0x12, 0x2c, 0x0a, 0x11, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x44, 0x6f, 0x77, 0x6e, 0x6c,
0x6f, 0x61, 0x64, 0x55, 0x52, 0x4c, 0x18, 0x18, 0x20, 0x01, 0x28, 0x09, 0x52, 0x11, 0x70, 0x6c,
0x75, 0x67, 0x69, 0x6e, 0x44, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x55, 0x52, 0x4c, 0x12,
0x61, 0x0a, 0x0f, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75,
0x6d, 0x73, 0x18, 0x1e, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x37, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d,
0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65, 0x73,
0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x2e, 0x50, 0x6c, 0x75,
0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x45, 0x6e, 0x74, 0x72,
0x79, 0x52, 0x0f, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75,
0x6d, 0x73, 0x12, 0x26, 0x0a, 0x0e, 0x72, 0x65, 0x74, 0x61, 0x69, 0x6e, 0x4f, 0x6e, 0x44, 0x65,
0x6c, 0x65, 0x74, 0x65, 0x18, 0x19, 0x20, 0x01, 0x28, 0x08, 0x52, 0x0e, 0x72, 0x65, 0x74, 0x61,
0x69, 0x6e, 0x4f, 0x6e, 0x44, 0x65, 0x6c, 0x65, 0x74, 0x65, 0x12, 0x2a, 0x0a, 0x07, 0x61, 0x6c,
0x69, 0x61, 0x73, 0x65, 0x73, 0x18, 0x1a, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x10, 0x2e, 0x70, 0x75,
0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x41, 0x6c, 0x69, 0x61, 0x73, 0x52, 0x07, 0x61,
0x6c, 0x69, 0x61, 0x73, 0x65, 0x73, 0x12, 0x20, 0x0a, 0x0b, 0x64, 0x65, 0x6c, 0x65, 0x74, 0x65,
0x64, 0x57, 0x69, 0x74, 0x68, 0x18, 0x1b, 0x20, 0x01, 0x28, 0x09, 0x52, 0x0b, 0x64, 0x65, 0x6c,
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
0x65, 0x74, 0x65, 0x64, 0x57, 0x69, 0x74, 0x68, 0x12, 0x2c, 0x0a, 0x11, 0x63, 0x72, 0x65, 0x61,
0x74, 0x65, 0x49, 0x66, 0x4e, 0x6f, 0x74, 0x45, 0x78, 0x69, 0x73, 0x74, 0x73, 0x18, 0x22, 0x20,
0x01, 0x28, 0x09, 0x52, 0x11, 0x63, 0x72, 0x65, 0x61, 0x74, 0x65, 0x49, 0x66, 0x4e, 0x6f, 0x74,
0x45, 0x78, 0x69, 0x73, 0x74, 0x73, 0x12, 0x1e, 0x0a, 0x0a, 0x61, 0x6c, 0x69, 0x61, 0x73, 0x53,
0x70, 0x65, 0x63, 0x73, 0x18, 0x1c, 0x20, 0x01, 0x28, 0x08, 0x52, 0x0a, 0x61, 0x6c, 0x69, 0x61,
0x73, 0x53, 0x70, 0x65, 0x63, 0x73, 0x12, 0x41, 0x0a, 0x0e, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65,
0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x18, 0x1d, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x19,
0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x53, 0x6f, 0x75, 0x72, 0x63,
0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x52, 0x0e, 0x73, 0x6f, 0x75, 0x72, 0x63,
0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x12, 0x33, 0x0a, 0x0a, 0x74, 0x72, 0x61,
0x6e, 0x73, 0x66, 0x6f, 0x72, 0x6d, 0x73, 0x18, 0x1f, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x13, 0x2e,
0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x43, 0x61, 0x6c, 0x6c, 0x62, 0x61,
0x63, 0x6b, 0x52, 0x0a, 0x74, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x6f, 0x72, 0x6d, 0x73, 0x12, 0x38,
0x0a, 0x17, 0x73, 0x75, 0x70, 0x70, 0x6f, 0x72, 0x74, 0x73, 0x52, 0x65, 0x73, 0x75, 0x6c, 0x74,
0x52, 0x65, 0x70, 0x6f, 0x72, 0x74, 0x69, 0x6e, 0x67, 0x18, 0x20, 0x20, 0x01, 0x28, 0x08, 0x52,
0x17, 0x73, 0x75, 0x70, 0x70, 0x6f, 0x72, 0x74, 0x73, 0x52, 0x65, 0x73, 0x75, 0x6c, 0x74, 0x52,
0x65, 0x70, 0x6f, 0x72, 0x74, 0x69, 0x6e, 0x67, 0x12, 0x18, 0x0a, 0x07, 0x70, 0x61, 0x63, 0x6b,
0x61, 0x67, 0x65, 0x18, 0x21, 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x70, 0x61, 0x63, 0x6b, 0x61,
0x67, 0x65, 0x1a, 0x2a, 0x0a, 0x14, 0x50, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x79, 0x44, 0x65,
0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x12, 0x12, 0x0a, 0x04, 0x75, 0x72,
0x6e, 0x73, 0x18, 0x01, 0x20, 0x03, 0x28, 0x09, 0x52, 0x04, 0x75, 0x72, 0x6e, 0x73, 0x1a, 0x58,
0x0a, 0x0e, 0x43, 0x75, 0x73, 0x74, 0x6f, 0x6d, 0x54, 0x69, 0x6d, 0x65, 0x6f, 0x75, 0x74, 0x73,
0x12, 0x16, 0x0a, 0x06, 0x63, 0x72, 0x65, 0x61, 0x74, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09,
0x52, 0x06, 0x63, 0x72, 0x65, 0x61, 0x74, 0x65, 0x12, 0x16, 0x0a, 0x06, 0x75, 0x70, 0x64, 0x61,
0x74, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x75, 0x70, 0x64, 0x61, 0x74, 0x65,
0x12, 0x16, 0x0a, 0x06, 0x64, 0x65, 0x6c, 0x65, 0x74, 0x65, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09,
0x52, 0x06, 0x64, 0x65, 0x6c, 0x65, 0x74, 0x65, 0x1a, 0x80, 0x01, 0x0a, 0x19, 0x50, 0x72, 0x6f,
0x70, 0x65, 0x72, 0x74, 0x79, 0x44, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65,
0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03, 0x6b, 0x65, 0x79, 0x18, 0x01, 0x20,
0x01, 0x28, 0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x4d, 0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75,
0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x37, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69,
0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65, 0x73, 0x6f,
0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x2e, 0x50, 0x72, 0x6f, 0x70,
0x65, 0x72, 0x74, 0x79, 0x44, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73,
0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x3a, 0x02, 0x38, 0x01, 0x1a, 0x3c, 0x0a, 0x0e, 0x50,
0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a,
0x03, 0x6b, 0x65, 0x79, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12,
0x14, 0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x05,
0x76, 0x61, 0x6c, 0x75, 0x65, 0x3a, 0x02, 0x38, 0x01, 0x1a, 0x42, 0x0a, 0x14, 0x50, 0x6c, 0x75,
0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x45, 0x6e, 0x74, 0x72,
0x79, 0x12, 0x10, 0x0a, 0x03, 0x6b, 0x65, 0x79, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03,
0x6b, 0x65, 0x79, 0x12, 0x14, 0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x18, 0x02, 0x20, 0x01,
0x28, 0x0c, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x3a, 0x02, 0x38, 0x01, 0x22, 0xed, 0x03,
0x0a, 0x18, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72,
0x63, 0x65, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x12, 0x10, 0x0a, 0x03, 0x75, 0x72,
0x6e, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x75, 0x72, 0x6e, 0x12, 0x0e, 0x0a, 0x02,
0x69, 0x64, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x02, 0x69, 0x64, 0x12, 0x2f, 0x0a, 0x06,
0x6f, 0x62, 0x6a, 0x65, 0x63, 0x74, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x17, 0x2e, 0x67,
0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75, 0x66, 0x2e, 0x53,
0x74, 0x72, 0x75, 0x63, 0x74, 0x52, 0x06, 0x6f, 0x62, 0x6a, 0x65, 0x63, 0x74, 0x12, 0x16, 0x0a,
0x06, 0x73, 0x74, 0x61, 0x62, 0x6c, 0x65, 0x18, 0x04, 0x20, 0x01, 0x28, 0x08, 0x52, 0x06, 0x73,
0x74, 0x61, 0x62, 0x6c, 0x65, 0x12, 0x18, 0x0a, 0x07, 0x73, 0x74, 0x61, 0x62, 0x6c, 0x65, 0x73,
0x18, 0x05, 0x20, 0x03, 0x28, 0x09, 0x52, 0x07, 0x73, 0x74, 0x61, 0x62, 0x6c, 0x65, 0x73, 0x12,
0x71, 0x0a, 0x14, 0x70, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x79, 0x44, 0x65, 0x70, 0x65, 0x6e,
0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x18, 0x06, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x3d, 0x2e,
0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74,
0x65, 0x72, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e,
0x73, 0x65, 0x2e, 0x50, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x79, 0x44, 0x65, 0x70, 0x65, 0x6e,
0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x52, 0x14, 0x70, 0x72,
0x6f, 0x70, 0x65, 0x72, 0x74, 0x79, 0x44, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69,
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
0x65, 0x73, 0x12, 0x29, 0x0a, 0x06, 0x72, 0x65, 0x73, 0x75, 0x6c, 0x74, 0x18, 0x07, 0x20, 0x01,
0x28, 0x0e, 0x32, 0x11, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52,
0x65, 0x73, 0x75, 0x6c, 0x74, 0x52, 0x06, 0x72, 0x65, 0x73, 0x75, 0x6c, 0x74, 0x1a, 0x2a, 0x0a,
0x14, 0x50, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x79, 0x44, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65,
0x6e, 0x63, 0x69, 0x65, 0x73, 0x12, 0x12, 0x0a, 0x04, 0x75, 0x72, 0x6e, 0x73, 0x18, 0x01, 0x20,
0x03, 0x28, 0x09, 0x52, 0x04, 0x75, 0x72, 0x6e, 0x73, 0x1a, 0x81, 0x01, 0x0a, 0x19, 0x50, 0x72,
0x6f, 0x70, 0x65, 0x72, 0x74, 0x79, 0x44, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69,
0x65, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03, 0x6b, 0x65, 0x79, 0x18, 0x01,
0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x4e, 0x0a, 0x05, 0x76, 0x61, 0x6c,
0x75, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x38, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d,
0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65, 0x73,
0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x2e, 0x50, 0x72,
0x6f, 0x70, 0x65, 0x72, 0x74, 0x79, 0x44, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69,
0x65, 0x73, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x3a, 0x02, 0x38, 0x01, 0x22, 0x65, 0x0a,
0x1e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63,
0x65, 0x4f, 0x75, 0x74, 0x70, 0x75, 0x74, 0x73, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x12,
0x10, 0x0a, 0x03, 0x75, 0x72, 0x6e, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x75, 0x72,
0x6e, 0x12, 0x31, 0x0a, 0x07, 0x6f, 0x75, 0x74, 0x70, 0x75, 0x74, 0x73, 0x18, 0x02, 0x20, 0x01,
0x28, 0x0b, 0x32, 0x17, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74,
0x6f, 0x62, 0x75, 0x66, 0x2e, 0x53, 0x74, 0x72, 0x75, 0x63, 0x74, 0x52, 0x07, 0x6f, 0x75, 0x74,
0x70, 0x75, 0x74, 0x73, 0x22, 0xcc, 0x03, 0x0a, 0x15, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63,
0x65, 0x49, 0x6e, 0x76, 0x6f, 0x6b, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x12, 0x10,
0x0a, 0x03, 0x74, 0x6f, 0x6b, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x74, 0x6f, 0x6b,
0x12, 0x2b, 0x0a, 0x04, 0x61, 0x72, 0x67, 0x73, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x17,
0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75, 0x66,
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
0x2e, 0x53, 0x74, 0x72, 0x75, 0x63, 0x74, 0x52, 0x04, 0x61, 0x72, 0x67, 0x73, 0x12, 0x1a, 0x0a,
0x08, 0x70, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52,
0x08, 0x70, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72, 0x12, 0x18, 0x0a, 0x07, 0x76, 0x65, 0x72,
0x73, 0x69, 0x6f, 0x6e, 0x18, 0x04, 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x76, 0x65, 0x72, 0x73,
0x69, 0x6f, 0x6e, 0x12, 0x28, 0x0a, 0x0f, 0x61, 0x63, 0x63, 0x65, 0x70, 0x74, 0x52, 0x65, 0x73,
0x6f, 0x75, 0x72, 0x63, 0x65, 0x73, 0x18, 0x05, 0x20, 0x01, 0x28, 0x08, 0x52, 0x0f, 0x61, 0x63,
0x63, 0x65, 0x70, 0x74, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x73, 0x12, 0x2c, 0x0a,
0x11, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x44, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x55,
0x52, 0x4c, 0x18, 0x06, 0x20, 0x01, 0x28, 0x09, 0x52, 0x11, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e,
0x44, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x55, 0x52, 0x4c, 0x12, 0x5f, 0x0a, 0x0f, 0x70,
0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x18, 0x08,
0x20, 0x03, 0x28, 0x0b, 0x32, 0x35, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63,
0x2e, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x49, 0x6e, 0x76, 0x6f, 0x6b, 0x65, 0x52,
0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x2e, 0x50, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65,
0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x52, 0x0f, 0x70, 0x6c, 0x75,
0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x12, 0x41, 0x0a, 0x0e,
0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x18, 0x07,
0x20, 0x01, 0x28, 0x0b, 0x32, 0x19, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63,
0x2e, 0x53, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x52,
0x0e, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x1a,
0x42, 0x0a, 0x14, 0x50, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75,
0x6d, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03, 0x6b, 0x65, 0x79, 0x18, 0x01,
0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x14, 0x0a, 0x05, 0x76, 0x61, 0x6c,
0x75, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0c, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x3a,
0x02, 0x38, 0x01, 0x22, 0xad, 0x06, 0x0a, 0x13, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65,
0x43, 0x61, 0x6c, 0x6c, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x12, 0x10, 0x0a, 0x03, 0x74,
0x6f, 0x6b, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x74, 0x6f, 0x6b, 0x12, 0x2b, 0x0a,
0x04, 0x61, 0x72, 0x67, 0x73, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x17, 0x2e, 0x67, 0x6f,
0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75, 0x66, 0x2e, 0x53, 0x74,
0x72, 0x75, 0x63, 0x74, 0x52, 0x04, 0x61, 0x72, 0x67, 0x73, 0x12, 0x5d, 0x0a, 0x0f, 0x61, 0x72,
0x67, 0x44, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x18, 0x03, 0x20,
0x03, 0x28, 0x0b, 0x32, 0x33, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e,
0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x43, 0x61, 0x6c, 0x6c, 0x52, 0x65, 0x71, 0x75,
0x65, 0x73, 0x74, 0x2e, 0x41, 0x72, 0x67, 0x44, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63,
0x69, 0x65, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x52, 0x0f, 0x61, 0x72, 0x67, 0x44, 0x65, 0x70,
0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x12, 0x1a, 0x0a, 0x08, 0x70, 0x72, 0x6f,
0x76, 0x69, 0x64, 0x65, 0x72, 0x18, 0x04, 0x20, 0x01, 0x28, 0x09, 0x52, 0x08, 0x70, 0x72, 0x6f,
0x76, 0x69, 0x64, 0x65, 0x72, 0x12, 0x18, 0x0a, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e,
0x18, 0x05, 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x12,
0x2c, 0x0a, 0x11, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x44, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61,
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
0x64, 0x55, 0x52, 0x4c, 0x18, 0x0d, 0x20, 0x01, 0x28, 0x09, 0x52, 0x11, 0x70, 0x6c, 0x75, 0x67,
0x69, 0x6e, 0x44, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x55, 0x52, 0x4c, 0x12, 0x5d, 0x0a,
0x0f, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73,
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
0x18, 0x10, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x33, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72,
0x70, 0x63, 0x2e, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x43, 0x61, 0x6c, 0x6c, 0x52,
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x2e, 0x50, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65,
0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x52, 0x0f, 0x70, 0x6c, 0x75,
0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x12, 0x41, 0x0a, 0x0e,
0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x18, 0x0f,
0x20, 0x01, 0x28, 0x0b, 0x32, 0x19, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63,
0x2e, 0x53, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x52,
0x0e, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x50, 0x6f, 0x73, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x1a,
0x2a, 0x0a, 0x14, 0x41, 0x72, 0x67, 0x75, 0x6d, 0x65, 0x6e, 0x74, 0x44, 0x65, 0x70, 0x65, 0x6e,
0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x12, 0x12, 0x0a, 0x04, 0x75, 0x72, 0x6e, 0x73, 0x18,
0x01, 0x20, 0x03, 0x28, 0x09, 0x52, 0x04, 0x75, 0x72, 0x6e, 0x73, 0x1a, 0x77, 0x0a, 0x14, 0x41,
0x72, 0x67, 0x44, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x45, 0x6e,
0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03, 0x6b, 0x65, 0x79, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09,
0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x49, 0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x18, 0x02,
0x20, 0x01, 0x28, 0x0b, 0x32, 0x33, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63,
0x2e, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x43, 0x61, 0x6c, 0x6c, 0x52, 0x65, 0x71,
0x75, 0x65, 0x73, 0x74, 0x2e, 0x41, 0x72, 0x67, 0x75, 0x6d, 0x65, 0x6e, 0x74, 0x44, 0x65, 0x70,
0x65, 0x6e, 0x64, 0x65, 0x6e, 0x63, 0x69, 0x65, 0x73, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65,
0x3a, 0x02, 0x38, 0x01, 0x1a, 0x42, 0x0a, 0x14, 0x50, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68,
0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03,
0x6b, 0x65, 0x79, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x14,
0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0c, 0x52, 0x05, 0x76,
0x61, 0x6c, 0x75, 0x65, 0x3a, 0x02, 0x38, 0x01, 0x4a, 0x04, 0x08, 0x06, 0x10, 0x07, 0x4a, 0x04,
0x08, 0x07, 0x10, 0x08, 0x4a, 0x04, 0x08, 0x08, 0x10, 0x09, 0x4a, 0x04, 0x08, 0x09, 0x10, 0x0a,
0x4a, 0x04, 0x08, 0x0a, 0x10, 0x0b, 0x4a, 0x04, 0x08, 0x0b, 0x10, 0x0c, 0x4a, 0x04, 0x08, 0x0c,
0x10, 0x0d, 0x4a, 0x04, 0x08, 0x0e, 0x10, 0x0f, 0x52, 0x07, 0x70, 0x72, 0x6f, 0x6a, 0x65, 0x63,
0x74, 0x52, 0x05, 0x73, 0x74, 0x61, 0x63, 0x6b, 0x52, 0x06, 0x63, 0x6f, 0x6e, 0x66, 0x69, 0x67,
0x52, 0x10, 0x63, 0x6f, 0x6e, 0x66, 0x69, 0x67, 0x53, 0x65, 0x63, 0x72, 0x65, 0x74, 0x4b, 0x65,
0x79, 0x73, 0x52, 0x06, 0x64, 0x72, 0x79, 0x52, 0x75, 0x6e, 0x52, 0x08, 0x70, 0x61, 0x72, 0x61,
0x6c, 0x6c, 0x65, 0x6c, 0x52, 0x0f, 0x6d, 0x6f, 0x6e, 0x69, 0x74, 0x6f, 0x72, 0x45, 0x6e, 0x64,
0x70, 0x6f, 0x69, 0x6e, 0x74, 0x52, 0x0c, 0x6f, 0x72, 0x67, 0x61, 0x6e, 0x69, 0x7a, 0x61, 0x74,
0x69, 0x6f, 0x6e, 0x22, 0xdc, 0x07, 0x0a, 0x18, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x6f, 0x72,
0x6d, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73,
0x12, 0x1d, 0x0a, 0x0a, 0x64, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x73, 0x5f, 0x6f, 0x6e, 0x18, 0x01,
0x20, 0x03, 0x28, 0x09, 0x52, 0x09, 0x64, 0x65, 0x70, 0x65, 0x6e, 0x64, 0x73, 0x4f, 0x6e, 0x12,
0x18, 0x0a, 0x07, 0x70, 0x72, 0x6f, 0x74, 0x65, 0x63, 0x74, 0x18, 0x02, 0x20, 0x01, 0x28, 0x08,
0x52, 0x07, 0x70, 0x72, 0x6f, 0x74, 0x65, 0x63, 0x74, 0x12, 0x25, 0x0a, 0x0e, 0x69, 0x67, 0x6e,
0x6f, 0x72, 0x65, 0x5f, 0x63, 0x68, 0x61, 0x6e, 0x67, 0x65, 0x73, 0x18, 0x03, 0x20, 0x03, 0x28,
0x09, 0x52, 0x0d, 0x69, 0x67, 0x6e, 0x6f, 0x72, 0x65, 0x43, 0x68, 0x61, 0x6e, 0x67, 0x65, 0x73,
0x12, 0x2c, 0x0a, 0x12, 0x72, 0x65, 0x70, 0x6c, 0x61, 0x63, 0x65, 0x5f, 0x6f, 0x6e, 0x5f, 0x63,
0x68, 0x61, 0x6e, 0x67, 0x65, 0x73, 0x18, 0x04, 0x20, 0x03, 0x28, 0x09, 0x52, 0x10, 0x72, 0x65,
0x70, 0x6c, 0x61, 0x63, 0x65, 0x4f, 0x6e, 0x43, 0x68, 0x61, 0x6e, 0x67, 0x65, 0x73, 0x12, 0x18,
0x0a, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x18, 0x05, 0x20, 0x01, 0x28, 0x09, 0x52,
0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x2a, 0x0a, 0x07, 0x61, 0x6c, 0x69, 0x61,
0x73, 0x65, 0x73, 0x18, 0x06, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x10, 0x2e, 0x70, 0x75, 0x6c, 0x75,
0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x41, 0x6c, 0x69, 0x61, 0x73, 0x52, 0x07, 0x61, 0x6c, 0x69,
0x61, 0x73, 0x65, 0x73, 0x12, 0x1a, 0x0a, 0x08, 0x70, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72,
0x18, 0x07, 0x20, 0x01, 0x28, 0x09, 0x52, 0x08, 0x70, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72,
0x12, 0x5a, 0x0a, 0x0f, 0x63, 0x75, 0x73, 0x74, 0x6f, 0x6d, 0x5f, 0x74, 0x69, 0x6d, 0x65, 0x6f,
0x75, 0x74, 0x73, 0x18, 0x08, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x31, 0x2e, 0x70, 0x75, 0x6c, 0x75,
0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65,
0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x2e, 0x43, 0x75,
0x73, 0x74, 0x6f, 0x6d, 0x54, 0x69, 0x6d, 0x65, 0x6f, 0x75, 0x74, 0x73, 0x52, 0x0e, 0x63, 0x75,
0x73, 0x74, 0x6f, 0x6d, 0x54, 0x69, 0x6d, 0x65, 0x6f, 0x75, 0x74, 0x73, 0x12, 0x2e, 0x0a, 0x13,
0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x5f, 0x64, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x5f,
0x75, 0x72, 0x6c, 0x18, 0x09, 0x20, 0x01, 0x28, 0x09, 0x52, 0x11, 0x70, 0x6c, 0x75, 0x67, 0x69,
0x6e, 0x44, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x55, 0x72, 0x6c, 0x12, 0x28, 0x0a, 0x10,
0x72, 0x65, 0x74, 0x61, 0x69, 0x6e, 0x5f, 0x6f, 0x6e, 0x5f, 0x64, 0x65, 0x6c, 0x65, 0x74, 0x65,
0x18, 0x0a, 0x20, 0x01, 0x28, 0x08, 0x52, 0x0e, 0x72, 0x65, 0x74, 0x61, 0x69, 0x6e, 0x4f, 0x6e,
0x44, 0x65, 0x6c, 0x65, 0x74, 0x65, 0x12, 0x21, 0x0a, 0x0c, 0x64, 0x65, 0x6c, 0x65, 0x74, 0x65,
0x64, 0x5f, 0x77, 0x69, 0x74, 0x68, 0x18, 0x0b, 0x20, 0x01, 0x28, 0x09, 0x52, 0x0b, 0x64, 0x65,
0x6c, 0x65, 0x74, 0x65, 0x64, 0x57, 0x69, 0x74, 0x68, 0x12, 0x37, 0x0a, 0x15, 0x64, 0x65, 0x6c,
0x65, 0x74, 0x65, 0x5f, 0x62, 0x65, 0x66, 0x6f, 0x72, 0x65, 0x5f, 0x72, 0x65, 0x70, 0x6c, 0x61,
0x63, 0x65, 0x18, 0x0c, 0x20, 0x01, 0x28, 0x08, 0x48, 0x00, 0x52, 0x13, 0x64, 0x65, 0x6c, 0x65,
0x74, 0x65, 0x42, 0x65, 0x66, 0x6f, 0x72, 0x65, 0x52, 0x65, 0x70, 0x6c, 0x61, 0x63, 0x65, 0x88,
0x01, 0x01, 0x12, 0x3a, 0x0a, 0x19, 0x61, 0x64, 0x64, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c,
0x5f, 0x73, 0x65, 0x63, 0x72, 0x65, 0x74, 0x5f, 0x6f, 0x75, 0x74, 0x70, 0x75, 0x74, 0x73, 0x18,
0x0d, 0x20, 0x03, 0x28, 0x09, 0x52, 0x17, 0x61, 0x64, 0x64, 0x69, 0x74, 0x69, 0x6f, 0x6e, 0x61,
0x6c, 0x53, 0x65, 0x63, 0x72, 0x65, 0x74, 0x4f, 0x75, 0x74, 0x70, 0x75, 0x74, 0x73, 0x12, 0x50,
0x0a, 0x09, 0x70, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72, 0x73, 0x18, 0x0e, 0x20, 0x03, 0x28,
0x0b, 0x32, 0x32, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x54, 0x72,
0x61, 0x6e, 0x73, 0x66, 0x6f, 0x72, 0x6d, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x4f,
0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x2e, 0x50, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72, 0x73,
0x45, 0x6e, 0x74, 0x72, 0x79, 0x52, 0x09, 0x70, 0x72, 0x6f, 0x76, 0x69, 0x64, 0x65, 0x72, 0x73,
0x12, 0x63, 0x0a, 0x10, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x5f, 0x63, 0x68, 0x65, 0x63, 0x6b,
0x73, 0x75, 0x6d, 0x73, 0x18, 0x0f, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x38, 0x2e, 0x70, 0x75, 0x6c,
0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x6f, 0x72, 0x6d,
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x2e,
0x50, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x45,
0x6e, 0x74, 0x72, 0x79, 0x52, 0x0f, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63,
0x6b, 0x73, 0x75, 0x6d, 0x73, 0x12, 0x2f, 0x0a, 0x14, 0x63, 0x72, 0x65, 0x61, 0x74, 0x65, 0x5f,
0x69, 0x66, 0x5f, 0x6e, 0x6f, 0x74, 0x5f, 0x65, 0x78, 0x69, 0x73, 0x74, 0x73, 0x18, 0x10, 0x20,
0x01, 0x28, 0x09, 0x52, 0x11, 0x63, 0x72, 0x65, 0x61, 0x74, 0x65, 0x49, 0x66, 0x4e, 0x6f, 0x74,
0x45, 0x78, 0x69, 0x73, 0x74, 0x73, 0x1a, 0x3c, 0x0a, 0x0e, 0x50, 0x72, 0x6f, 0x76, 0x69, 0x64,
0x65, 0x72, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03, 0x6b, 0x65, 0x79, 0x18,
0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x14, 0x0a, 0x05, 0x76, 0x61,
0x6c, 0x75, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65,
0x3a, 0x02, 0x38, 0x01, 0x1a, 0x42, 0x0a, 0x14, 0x50, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68,
0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03,
0x6b, 0x65, 0x79, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x14,
0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0c, 0x52, 0x05, 0x76,
0x61, 0x6c, 0x75, 0x65, 0x3a, 0x02, 0x38, 0x01, 0x42, 0x18, 0x0a, 0x16, 0x5f, 0x64, 0x65, 0x6c,
0x65, 0x74, 0x65, 0x5f, 0x62, 0x65, 0x66, 0x6f, 0x72, 0x65, 0x5f, 0x72, 0x65, 0x70, 0x6c, 0x61,
0x63, 0x65, 0x22, 0xe2, 0x01, 0x0a, 0x10, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x6f, 0x72, 0x6d,
0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x12, 0x12, 0x0a, 0x04, 0x74, 0x79, 0x70, 0x65, 0x18,
0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x04, 0x74, 0x79, 0x70, 0x65, 0x12, 0x12, 0x0a, 0x04, 0x6e,
0x61, 0x6d, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x12,
0x16, 0x0a, 0x06, 0x63, 0x75, 0x73, 0x74, 0x6f, 0x6d, 0x18, 0x03, 0x20, 0x01, 0x28, 0x08, 0x52,
0x06, 0x63, 0x75, 0x73, 0x74, 0x6f, 0x6d, 0x12, 0x16, 0x0a, 0x06, 0x70, 0x61, 0x72, 0x65, 0x6e,
0x74, 0x18, 0x04, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x70, 0x61, 0x72, 0x65, 0x6e, 0x74, 0x12,
0x37, 0x0a, 0x0a, 0x70, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x69, 0x65, 0x73, 0x18, 0x05, 0x20,
0x01, 0x28, 0x0b, 0x32, 0x17, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x70, 0x72, 0x6f,
0x74, 0x6f, 0x62, 0x75, 0x66, 0x2e, 0x53, 0x74, 0x72, 0x75, 0x63, 0x74, 0x52, 0x0a, 0x70, 0x72,
0x6f, 0x70, 0x65, 0x72, 0x74, 0x69, 0x65, 0x73, 0x12, 0x3d, 0x0a, 0x07, 0x6f, 0x70, 0x74, 0x69,
0x6f, 0x6e, 0x73, 0x18, 0x06, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x23, 0x2e, 0x70, 0x75, 0x6c, 0x75,
0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x6f, 0x72, 0x6d, 0x52,
0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x52, 0x07,
0x6f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x22, 0x8b, 0x01, 0x0a, 0x11, 0x54, 0x72, 0x61, 0x6e,
0x73, 0x66, 0x6f, 0x72, 0x6d, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x12, 0x37, 0x0a,
0x0a, 0x70, 0x72, 0x6f, 0x70, 0x65, 0x72, 0x74, 0x69, 0x65, 0x73, 0x18, 0x01, 0x20, 0x01, 0x28,
0x0b, 0x32, 0x17, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x62, 0x75, 0x66, 0x2e, 0x53, 0x74, 0x72, 0x75, 0x63, 0x74, 0x52, 0x0a, 0x70, 0x72, 0x6f, 0x70,
0x65, 0x72, 0x74, 0x69, 0x65, 0x73, 0x12, 0x3d, 0x0a, 0x07, 0x6f, 0x70, 0x74, 0x69, 0x6f, 0x6e,
0x73, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x23, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69,
0x72, 0x70, 0x63, 0x2e, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x6f, 0x72, 0x6d, 0x52, 0x65, 0x73,
0x6f, 0x75, 0x72, 0x63, 0x65, 0x4f, 0x70, 0x74, 0x69, 0x6f, 0x6e, 0x73, 0x52, 0x07, 0x6f, 0x70,
0x74, 0x69, 0x6f, 0x6e, 0x73, 0x22, 0xd8, 0x02, 0x0a, 0x16, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74,
0x65, 0x72, 0x50, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74,
0x12, 0x12, 0x0a, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x04,
0x6e, 0x61, 0x6d, 0x65, 0x12, 0x18, 0x0a, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x18,
0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x2e,
0x0a, 0x13, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x5f, 0x64, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61,
0x64, 0x5f, 0x75, 0x72, 0x6c, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52, 0x11, 0x70, 0x6c, 0x75,
0x67, 0x69, 0x6e, 0x44, 0x6f, 0x77, 0x6e, 0x6c, 0x6f, 0x61, 0x64, 0x55, 0x72, 0x6c, 0x12, 0x61,
0x0a, 0x10, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x5f, 0x63, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75,
0x6d, 0x73, 0x18, 0x04, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x36, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d,
0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x50, 0x61, 0x63,
0x6b, 0x61, 0x67, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x2e, 0x50, 0x6c, 0x75, 0x67,
0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x45, 0x6e, 0x74, 0x72, 0x79,
0x52, 0x0f, 0x70, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d,
0x73, 0x12, 0x39, 0x0a, 0x09, 0x70, 0x61, 0x72, 0x61, 0x6d, 0x65, 0x74, 0x65, 0x72, 0x18, 0x05,
0x20, 0x01, 0x28, 0x0b, 0x32, 0x1b, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63,
0x2e, 0x50, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x50, 0x61, 0x72, 0x61, 0x6d, 0x65, 0x74, 0x65,
0x72, 0x52, 0x09, 0x70, 0x61, 0x72, 0x61, 0x6d, 0x65, 0x74, 0x65, 0x72, 0x1a, 0x42, 0x0a, 0x14,
0x50, 0x6c, 0x75, 0x67, 0x69, 0x6e, 0x43, 0x68, 0x65, 0x63, 0x6b, 0x73, 0x75, 0x6d, 0x73, 0x45,
0x6e, 0x74, 0x72, 0x79, 0x12, 0x10, 0x0a, 0x03, 0x6b, 0x65, 0x79, 0x18, 0x01, 0x20, 0x01, 0x28,
0x09, 0x52, 0x03, 0x6b, 0x65, 0x79, 0x12, 0x14, 0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x18,
0x02, 0x20, 0x01, 0x28, 0x0c, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x3a, 0x02, 0x38, 0x01,
0x22, 0x2b, 0x0a, 0x17, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x50, 0x61, 0x63, 0x6b,
0x61, 0x67, 0x65, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x12, 0x10, 0x0a, 0x03, 0x72,
0x65, 0x66, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x72, 0x65, 0x66, 0x22, 0x6e, 0x0a,
0x10, 0x50, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x50, 0x61, 0x72, 0x61, 0x6d, 0x65, 0x74, 0x65,
0x72, 0x12, 0x12, 0x0a, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52,
0x04, 0x6e, 0x61, 0x6d, 0x65, 0x12, 0x18, 0x0a, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e,
0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x76, 0x65, 0x72, 0x73, 0x69, 0x6f, 0x6e, 0x12,
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
0x2c, 0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x16,
0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75, 0x66,
0x2e, 0x56, 0x61, 0x6c, 0x75, 0x65, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x2a, 0x29, 0x0a,
0x06, 0x52, 0x65, 0x73, 0x75, 0x6c, 0x74, 0x12, 0x0b, 0x0a, 0x07, 0x53, 0x55, 0x43, 0x43, 0x45,
0x53, 0x53, 0x10, 0x00, 0x12, 0x08, 0x0a, 0x04, 0x46, 0x41, 0x49, 0x4c, 0x10, 0x01, 0x12, 0x08,
0x0a, 0x04, 0x53, 0x4b, 0x49, 0x50, 0x10, 0x02, 0x32, 0x81, 0x06, 0x0a, 0x0f, 0x52, 0x65, 0x73,
0x6f, 0x75, 0x72, 0x63, 0x65, 0x4d, 0x6f, 0x6e, 0x69, 0x74, 0x6f, 0x72, 0x12, 0x5a, 0x0a, 0x0f,
0x53, 0x75, 0x70, 0x70, 0x6f, 0x72, 0x74, 0x73, 0x46, 0x65, 0x61, 0x74, 0x75, 0x72, 0x65, 0x12,
0x21, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x53, 0x75, 0x70, 0x70,
0x6f, 0x72, 0x74, 0x73, 0x46, 0x65, 0x61, 0x74, 0x75, 0x72, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65,
0x73, 0x74, 0x1a, 0x22, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x53,
0x75, 0x70, 0x70, 0x6f, 0x72, 0x74, 0x73, 0x46, 0x65, 0x61, 0x74, 0x75, 0x72, 0x65, 0x52, 0x65,
0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x22, 0x00, 0x12, 0x47, 0x0a, 0x06, 0x49, 0x6e, 0x76, 0x6f,
0x6b, 0x65, 0x12, 0x20, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52,
0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x49, 0x6e, 0x76, 0x6f, 0x6b, 0x65, 0x52, 0x65, 0x71,
0x75, 0x65, 0x73, 0x74, 0x1a, 0x19, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63,
0x2e, 0x49, 0x6e, 0x76, 0x6f, 0x6b, 0x65, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x22,
Implement the `CreateIfNotExists` resource option This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189
2024-05-23 16:14:55 +00:00
0x00, 0x12, 0x4f, 0x0a, 0x0c, 0x53, 0x74, 0x72, 0x65, 0x61, 0x6d, 0x49, 0x6e, 0x76, 0x6f, 0x6b,
0x65, 0x12, 0x20, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65,
0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x49, 0x6e, 0x76, 0x6f, 0x6b, 0x65, 0x52, 0x65, 0x71, 0x75,
0x65, 0x73, 0x74, 0x1a, 0x19, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e,
0x49, 0x6e, 0x76, 0x6f, 0x6b, 0x65, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x22, 0x00,
0x30, 0x01, 0x12, 0x41, 0x0a, 0x04, 0x43, 0x61, 0x6c, 0x6c, 0x12, 0x1e, 0x2e, 0x70, 0x75, 0x6c,
0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x43,
0x61, 0x6c, 0x6c, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x1a, 0x17, 0x2e, 0x70, 0x75, 0x6c,
0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x43, 0x61, 0x6c, 0x6c, 0x52, 0x65, 0x73, 0x70, 0x6f,
0x6e, 0x73, 0x65, 0x22, 0x00, 0x12, 0x51, 0x0a, 0x0c, 0x52, 0x65, 0x61, 0x64, 0x52, 0x65, 0x73,
0x6f, 0x75, 0x72, 0x63, 0x65, 0x12, 0x1e, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70,
0x63, 0x2e, 0x52, 0x65, 0x61, 0x64, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65,
0x71, 0x75, 0x65, 0x73, 0x74, 0x1a, 0x1f, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70,
0x63, 0x2e, 0x52, 0x65, 0x61, 0x64, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65,
0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x22, 0x00, 0x12, 0x5d, 0x0a, 0x10, 0x52, 0x65, 0x67, 0x69,
0x73, 0x74, 0x65, 0x72, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x12, 0x22, 0x2e, 0x70,
0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65,
0x72, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74,
0x1a, 0x23, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52, 0x65, 0x67,
0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x52, 0x65, 0x73,
0x70, 0x6f, 0x6e, 0x73, 0x65, 0x22, 0x00, 0x12, 0x5e, 0x0a, 0x17, 0x52, 0x65, 0x67, 0x69, 0x73,
0x74, 0x65, 0x72, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x4f, 0x75, 0x74, 0x70, 0x75,
0x74, 0x73, 0x12, 0x29, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x52,
0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x52, 0x65, 0x73, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x4f,
0x75, 0x74, 0x70, 0x75, 0x74, 0x73, 0x52, 0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x1a, 0x16, 0x2e,
0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75, 0x66, 0x2e,
0x45, 0x6d, 0x70, 0x74, 0x79, 0x22, 0x00, 0x12, 0x47, 0x0a, 0x16, 0x52, 0x65, 0x67, 0x69, 0x73,
0x74, 0x65, 0x72, 0x53, 0x74, 0x61, 0x63, 0x6b, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x6f, 0x72,
0x6d, 0x12, 0x13, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e, 0x43, 0x61,
0x6c, 0x6c, 0x62, 0x61, 0x63, 0x6b, 0x1a, 0x16, 0x2e, 0x67, 0x6f, 0x6f, 0x67, 0x6c, 0x65, 0x2e,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75, 0x66, 0x2e, 0x45, 0x6d, 0x70, 0x74, 0x79, 0x22, 0x00,
0x12, 0x5a, 0x0a, 0x0f, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x50, 0x61, 0x63, 0x6b,
0x61, 0x67, 0x65, 0x12, 0x21, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72, 0x70, 0x63, 0x2e,
0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x50, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x52,
0x65, 0x71, 0x75, 0x65, 0x73, 0x74, 0x1a, 0x22, 0x2e, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72,
0x70, 0x63, 0x2e, 0x52, 0x65, 0x67, 0x69, 0x73, 0x74, 0x65, 0x72, 0x50, 0x61, 0x63, 0x6b, 0x61,
0x67, 0x65, 0x52, 0x65, 0x73, 0x70, 0x6f, 0x6e, 0x73, 0x65, 0x22, 0x00, 0x42, 0x34, 0x5a, 0x32,
0x67, 0x69, 0x74, 0x68, 0x75, 0x62, 0x2e, 0x63, 0x6f, 0x6d, 0x2f, 0x70, 0x75, 0x6c, 0x75, 0x6d,
0x69, 0x2f, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x2f, 0x73, 0x64, 0x6b, 0x2f, 0x76, 0x33, 0x2f,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2f, 0x67, 0x6f, 0x3b, 0x70, 0x75, 0x6c, 0x75, 0x6d, 0x69, 0x72,
0x70, 0x63, 0x62, 0x06, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x33,
}
var (
file_pulumi_resource_proto_rawDescOnce sync.Once
file_pulumi_resource_proto_rawDescData = file_pulumi_resource_proto_rawDesc
)
func file_pulumi_resource_proto_rawDescGZIP() []byte {
file_pulumi_resource_proto_rawDescOnce.Do(func() {
file_pulumi_resource_proto_rawDescData = protoimpl.X.CompressGZIP(file_pulumi_resource_proto_rawDescData)
})
return file_pulumi_resource_proto_rawDescData
}
var file_pulumi_resource_proto_enumTypes = make([]protoimpl.EnumInfo, 1)
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
var file_pulumi_resource_proto_msgTypes = make([]protoimpl.MessageInfo, 30)
2023-03-04 22:11:52 +00:00
var file_pulumi_resource_proto_goTypes = []interface{}{
(Result)(0), // 0: pulumirpc.Result
(*SupportsFeatureRequest)(nil), // 1: pulumirpc.SupportsFeatureRequest
(*SupportsFeatureResponse)(nil), // 2: pulumirpc.SupportsFeatureResponse
(*ReadResourceRequest)(nil), // 3: pulumirpc.ReadResourceRequest
(*ReadResourceResponse)(nil), // 4: pulumirpc.ReadResourceResponse
(*RegisterResourceRequest)(nil), // 5: pulumirpc.RegisterResourceRequest
(*RegisterResourceResponse)(nil), // 6: pulumirpc.RegisterResourceResponse
(*RegisterResourceOutputsRequest)(nil), // 7: pulumirpc.RegisterResourceOutputsRequest
(*ResourceInvokeRequest)(nil), // 8: pulumirpc.ResourceInvokeRequest
(*ResourceCallRequest)(nil), // 9: pulumirpc.ResourceCallRequest
(*TransformResourceOptions)(nil), // 10: pulumirpc.TransformResourceOptions
(*TransformRequest)(nil), // 11: pulumirpc.TransformRequest
(*TransformResponse)(nil), // 12: pulumirpc.TransformResponse
(*RegisterPackageRequest)(nil), // 13: pulumirpc.RegisterPackageRequest
(*RegisterPackageResponse)(nil), // 14: pulumirpc.RegisterPackageResponse
(*PackageParameter)(nil), // 15: pulumirpc.PackageParameter
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
nil, // 16: pulumirpc.ReadResourceRequest.PluginChecksumsEntry
(*RegisterResourceRequest_PropertyDependencies)(nil), // 17: pulumirpc.RegisterResourceRequest.PropertyDependencies
(*RegisterResourceRequest_CustomTimeouts)(nil), // 18: pulumirpc.RegisterResourceRequest.CustomTimeouts
nil, // 19: pulumirpc.RegisterResourceRequest.PropertyDependenciesEntry
nil, // 20: pulumirpc.RegisterResourceRequest.ProvidersEntry
nil, // 21: pulumirpc.RegisterResourceRequest.PluginChecksumsEntry
(*RegisterResourceResponse_PropertyDependencies)(nil), // 22: pulumirpc.RegisterResourceResponse.PropertyDependencies
nil, // 23: pulumirpc.RegisterResourceResponse.PropertyDependenciesEntry
nil, // 24: pulumirpc.ResourceInvokeRequest.PluginChecksumsEntry
(*ResourceCallRequest_ArgumentDependencies)(nil), // 25: pulumirpc.ResourceCallRequest.ArgumentDependencies
nil, // 26: pulumirpc.ResourceCallRequest.ArgDependenciesEntry
nil, // 27: pulumirpc.ResourceCallRequest.PluginChecksumsEntry
nil, // 28: pulumirpc.TransformResourceOptions.ProvidersEntry
nil, // 29: pulumirpc.TransformResourceOptions.PluginChecksumsEntry
nil, // 30: pulumirpc.RegisterPackageRequest.PluginChecksumsEntry
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
(*structpb.Struct)(nil), // 31: google.protobuf.Struct
(*SourcePosition)(nil), // 32: pulumirpc.SourcePosition
(*Alias)(nil), // 33: pulumirpc.Alias
(*Callback)(nil), // 34: pulumirpc.Callback
(*structpb.Value)(nil), // 35: google.protobuf.Value
(*InvokeResponse)(nil), // 36: pulumirpc.InvokeResponse
(*CallResponse)(nil), // 37: pulumirpc.CallResponse
(*emptypb.Empty)(nil), // 38: google.protobuf.Empty
2023-03-04 22:11:52 +00:00
}
var file_pulumi_resource_proto_depIdxs = []int32{
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
31, // 0: pulumirpc.ReadResourceRequest.properties:type_name -> google.protobuf.Struct
16, // 1: pulumirpc.ReadResourceRequest.pluginChecksums:type_name -> pulumirpc.ReadResourceRequest.PluginChecksumsEntry
32, // 2: pulumirpc.ReadResourceRequest.sourcePosition:type_name -> pulumirpc.SourcePosition
31, // 3: pulumirpc.ReadResourceResponse.properties:type_name -> google.protobuf.Struct
31, // 4: pulumirpc.RegisterResourceRequest.object:type_name -> google.protobuf.Struct
19, // 5: pulumirpc.RegisterResourceRequest.propertyDependencies:type_name -> pulumirpc.RegisterResourceRequest.PropertyDependenciesEntry
18, // 6: pulumirpc.RegisterResourceRequest.customTimeouts:type_name -> pulumirpc.RegisterResourceRequest.CustomTimeouts
20, // 7: pulumirpc.RegisterResourceRequest.providers:type_name -> pulumirpc.RegisterResourceRequest.ProvidersEntry
21, // 8: pulumirpc.RegisterResourceRequest.pluginChecksums:type_name -> pulumirpc.RegisterResourceRequest.PluginChecksumsEntry
33, // 9: pulumirpc.RegisterResourceRequest.aliases:type_name -> pulumirpc.Alias
32, // 10: pulumirpc.RegisterResourceRequest.sourcePosition:type_name -> pulumirpc.SourcePosition
34, // 11: pulumirpc.RegisterResourceRequest.transforms:type_name -> pulumirpc.Callback
31, // 12: pulumirpc.RegisterResourceResponse.object:type_name -> google.protobuf.Struct
23, // 13: pulumirpc.RegisterResourceResponse.propertyDependencies:type_name -> pulumirpc.RegisterResourceResponse.PropertyDependenciesEntry
0, // 14: pulumirpc.RegisterResourceResponse.result:type_name -> pulumirpc.Result
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
31, // 15: pulumirpc.RegisterResourceOutputsRequest.outputs:type_name -> google.protobuf.Struct
31, // 16: pulumirpc.ResourceInvokeRequest.args:type_name -> google.protobuf.Struct
24, // 17: pulumirpc.ResourceInvokeRequest.pluginChecksums:type_name -> pulumirpc.ResourceInvokeRequest.PluginChecksumsEntry
32, // 18: pulumirpc.ResourceInvokeRequest.sourcePosition:type_name -> pulumirpc.SourcePosition
31, // 19: pulumirpc.ResourceCallRequest.args:type_name -> google.protobuf.Struct
26, // 20: pulumirpc.ResourceCallRequest.argDependencies:type_name -> pulumirpc.ResourceCallRequest.ArgDependenciesEntry
27, // 21: pulumirpc.ResourceCallRequest.pluginChecksums:type_name -> pulumirpc.ResourceCallRequest.PluginChecksumsEntry
32, // 22: pulumirpc.ResourceCallRequest.sourcePosition:type_name -> pulumirpc.SourcePosition
33, // 23: pulumirpc.TransformResourceOptions.aliases:type_name -> pulumirpc.Alias
18, // 24: pulumirpc.TransformResourceOptions.custom_timeouts:type_name -> pulumirpc.RegisterResourceRequest.CustomTimeouts
28, // 25: pulumirpc.TransformResourceOptions.providers:type_name -> pulumirpc.TransformResourceOptions.ProvidersEntry
29, // 26: pulumirpc.TransformResourceOptions.plugin_checksums:type_name -> pulumirpc.TransformResourceOptions.PluginChecksumsEntry
31, // 27: pulumirpc.TransformRequest.properties:type_name -> google.protobuf.Struct
10, // 28: pulumirpc.TransformRequest.options:type_name -> pulumirpc.TransformResourceOptions
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
31, // 29: pulumirpc.TransformResponse.properties:type_name -> google.protobuf.Struct
10, // 30: pulumirpc.TransformResponse.options:type_name -> pulumirpc.TransformResourceOptions
30, // 31: pulumirpc.RegisterPackageRequest.plugin_checksums:type_name -> pulumirpc.RegisterPackageRequest.PluginChecksumsEntry
15, // 32: pulumirpc.RegisterPackageRequest.parameter:type_name -> pulumirpc.PackageParameter
35, // 33: pulumirpc.PackageParameter.value:type_name -> google.protobuf.Value
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
17, // 34: pulumirpc.RegisterResourceRequest.PropertyDependenciesEntry.value:type_name -> pulumirpc.RegisterResourceRequest.PropertyDependencies
22, // 35: pulumirpc.RegisterResourceResponse.PropertyDependenciesEntry.value:type_name -> pulumirpc.RegisterResourceResponse.PropertyDependencies
25, // 36: pulumirpc.ResourceCallRequest.ArgDependenciesEntry.value:type_name -> pulumirpc.ResourceCallRequest.ArgumentDependencies
1, // 37: pulumirpc.ResourceMonitor.SupportsFeature:input_type -> pulumirpc.SupportsFeatureRequest
8, // 38: pulumirpc.ResourceMonitor.Invoke:input_type -> pulumirpc.ResourceInvokeRequest
8, // 39: pulumirpc.ResourceMonitor.StreamInvoke:input_type -> pulumirpc.ResourceInvokeRequest
9, // 40: pulumirpc.ResourceMonitor.Call:input_type -> pulumirpc.ResourceCallRequest
3, // 41: pulumirpc.ResourceMonitor.ReadResource:input_type -> pulumirpc.ReadResourceRequest
5, // 42: pulumirpc.ResourceMonitor.RegisterResource:input_type -> pulumirpc.RegisterResourceRequest
7, // 43: pulumirpc.ResourceMonitor.RegisterResourceOutputs:input_type -> pulumirpc.RegisterResourceOutputsRequest
34, // 44: pulumirpc.ResourceMonitor.RegisterStackTransform:input_type -> pulumirpc.Callback
13, // 45: pulumirpc.ResourceMonitor.RegisterPackage:input_type -> pulumirpc.RegisterPackageRequest
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
2, // 46: pulumirpc.ResourceMonitor.SupportsFeature:output_type -> pulumirpc.SupportsFeatureResponse
36, // 47: pulumirpc.ResourceMonitor.Invoke:output_type -> pulumirpc.InvokeResponse
36, // 48: pulumirpc.ResourceMonitor.StreamInvoke:output_type -> pulumirpc.InvokeResponse
37, // 49: pulumirpc.ResourceMonitor.Call:output_type -> pulumirpc.CallResponse
4, // 50: pulumirpc.ResourceMonitor.ReadResource:output_type -> pulumirpc.ReadResourceResponse
6, // 51: pulumirpc.ResourceMonitor.RegisterResource:output_type -> pulumirpc.RegisterResourceResponse
38, // 52: pulumirpc.ResourceMonitor.RegisterResourceOutputs:output_type -> google.protobuf.Empty
38, // 53: pulumirpc.ResourceMonitor.RegisterStackTransform:output_type -> google.protobuf.Empty
14, // 54: pulumirpc.ResourceMonitor.RegisterPackage:output_type -> pulumirpc.RegisterPackageResponse
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
46, // [46:55] is the sub-list for method output_type
37, // [37:46] is the sub-list for method input_type
37, // [37:37] is the sub-list for extension type_name
37, // [37:37] is the sub-list for extension extendee
0, // [0:37] is the sub-list for field type_name
}
func init() { file_pulumi_resource_proto_init() }
func file_pulumi_resource_proto_init() {
if File_pulumi_resource_proto != nil {
return
}
file_pulumi_provider_proto_init()
file_pulumi_alias_proto_init()
[engine] Add support for source positions These changes add support for passing source position information in gRPC metadata and recording the source position that corresponds to a resource registration in the statefile. Enabling source position information in the resource model can provide substantial benefits, including but not limited to: - Better errors from the Pulumi CLI - Go-to-defintion for resources in state - Editor integration for errors, etc. from `pulumi preview` Source positions are (file, line) or (file, line, column) tuples represented as URIs. The line and column are stored in the fragment portion of the URI as "line(,column)?". The scheme of the URI and the form of its path component depends on the context in which it is generated or used: - During an active update, the URI's scheme is `file` and paths are absolute filesystem paths. This allows consumers to easily access arbitrary files that are available on the host. - In a statefile, the URI's scheme is `project` and paths are relative to the project root. This allows consumers to resolve source positions relative to the project file in different contexts irrespective of the location of the project itself (e.g. given a project-relative path and the URL of the project's root on GitHub, one can build a GitHub URL for the source position). During an update, source position information may be attached to gRPC calls as "source-position" metadata. This allows arbitrary calls to be associated with source positions without changes to their protobuf payloads. Modifying the protobuf payloads is also a viable approach, but is somewhat more invasive than attaching metadata, and requires changes to every call signature. Source positions should reflect the position in user code that initiated a resource model operation (e.g. the source position passed with `RegisterResource` for `pet` in the example above should be the source position in `index.ts`, _not_ the source position in the Pulumi SDK). In general, the Pulumi SDK should be able to infer the source position of the resource registration, as the relationship between a resource registration and its corresponding user code should be static per SDK. Source positions in state files will be stored as a new `registeredAt` property on each resource. This property is optional.
2023-06-29 18:41:19 +00:00
file_pulumi_source_proto_init()
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
file_pulumi_callback_proto_init()
if !protoimpl.UnsafeEnabled {
file_pulumi_resource_proto_msgTypes[0].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*SupportsFeatureRequest); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
file_pulumi_resource_proto_msgTypes[1].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*SupportsFeatureResponse); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
file_pulumi_resource_proto_msgTypes[2].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*ReadResourceRequest); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
file_pulumi_resource_proto_msgTypes[3].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*ReadResourceResponse); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
file_pulumi_resource_proto_msgTypes[4].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*RegisterResourceRequest); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
file_pulumi_resource_proto_msgTypes[5].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*RegisterResourceResponse); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
file_pulumi_resource_proto_msgTypes[6].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*RegisterResourceOutputsRequest); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
file_pulumi_resource_proto_msgTypes[7].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*ResourceInvokeRequest); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
Split CallRequest into ResourceCallRequest (#15404) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> Similar to what we did to the `InvokeRequest` a while ago. We're currently using the same protobuf structure for `Provider.Call` and `ResourceMonitor.Call` despite different field sets being filled in for each of them. This splits the structure into `CallRequest` for providers and `ResourceCallRequest` for the resource monitor. A number of fields in each are removed and marked reserved with a comment explaining why. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-08 13:16:23 +00:00
file_pulumi_resource_proto_msgTypes[8].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*ResourceCallRequest); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
file_pulumi_resource_proto_msgTypes[9].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*TransformResourceOptions); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
Pass provider checksums in requests and save to state (#13789) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This extends the resource monitor interface with fields for plugin checksums (on top of the existing plugin version and download url fields). These fields are threaded through the engine and are persisted in resource state. The sent or saved data is then used when installing plugins to ensure that the checksums match what was recorded at the time the SDK was built. Similar to https://github.com/pulumi/pulumi/pull/13776 nothing is using this yet, but this lays the engine side plumbing for them. ## Checklist - [ ] I have run `make tidy` to update any new dependencies - [ ] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-09-11 15:54:07 +00:00
file_pulumi_resource_proto_msgTypes[10].Exporter = func(v interface{}, i int) interface{} {
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
switch v := v.(*TransformRequest); i {
Split CallRequest into ResourceCallRequest (#15404) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> Similar to what we did to the `InvokeRequest` a while ago. We're currently using the same protobuf structure for `Provider.Call` and `ResourceMonitor.Call` despite different field sets being filled in for each of them. This splits the structure into `CallRequest` for providers and `ResourceCallRequest` for the resource monitor. A number of fields in each are removed and marked reserved with a comment explaining why. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-08 13:16:23 +00:00
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
file_pulumi_resource_proto_msgTypes[11].Exporter = func(v interface{}, i int) interface{} {
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
switch v := v.(*TransformResponse); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
file_pulumi_resource_proto_msgTypes[12].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*RegisterPackageRequest); i {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
file_pulumi_resource_proto_msgTypes[13].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*RegisterPackageResponse); i {
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
file_pulumi_resource_proto_msgTypes[14].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*PackageParameter); i {
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
RegisterProvider engine work (#16241) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support for a `RegisterProvider` method to the engine. This allows an SDK process to send the information for a package (name, version, url, etc, and parameter in the future) and get back a UUID for that run of the engine that can be used to re-lookup that information. That allows the SDK to just send the `provider` field in `RegisterResourceRequest` instead of filling in `version`, `pluginDownloadURL` etc (and importantly not having to fill in `parameter` for parameterised providers, which could be a large amount of data). This doesn't update any of the SDKs to yet use this method. We can do that piecemeal, but it will require core sdk and codegen changes for each language. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-05-23 06:16:59 +00:00
file_pulumi_resource_proto_msgTypes[16].Exporter = func(v interface{}, i int) interface{} {
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
switch v := v.(*RegisterResourceRequest_PropertyDependencies); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
file_pulumi_resource_proto_msgTypes[17].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*RegisterResourceRequest_CustomTimeouts); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
file_pulumi_resource_proto_msgTypes[21].Exporter = func(v interface{}, i int) interface{} {
switch v := v.(*RegisterResourceResponse_PropertyDependencies); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
file_pulumi_resource_proto_msgTypes[24].Exporter = func(v interface{}, i int) interface{} {
Split CallRequest into ResourceCallRequest (#15404) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> Similar to what we did to the `InvokeRequest` a while ago. We're currently using the same protobuf structure for `Provider.Call` and `ResourceMonitor.Call` despite different field sets being filled in for each of them. This splits the structure into `CallRequest` for providers and `ResourceCallRequest` for the resource monitor. A number of fields in each are removed and marked reserved with a comment explaining why. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-08 13:16:23 +00:00
switch v := v.(*ResourceCallRequest_ArgumentDependencies); i {
case 0:
return &v.state
case 1:
return &v.sizeCache
case 2:
return &v.unknownFields
default:
return nil
}
}
}
Engine support for remote transforms (#15290) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds support to the engine for "remote transformations". A transform is "remote" because it is being invoked via the engine on receiving a resource registration, rather than being ran locally in process before sending a resource registration. These transforms can also span multiple process boundaries, e.g. a transform function in a user program, then a transform function in a component library, both running for a resource registered by another component library. The underlying new feature here is the idea of a `Callback`. The expectation is we're going to use callbacks for multiple features so these are _not_ defined in terms of transformations. A callback is an untyped byte array (usually will be a protobuf message), plus an address to define which server should be invoked to do the callback, and a token to identify it. A language sdk can start up and serve a `Callbacks` service, keep a mapping of tokens to in-process functions (currently just using UUID's for this), and then pass that service address and token to the engine to be invoked later on. The engine uses these callbacks to track transformations callbacks per resource, and on a new resource registrations invokes each relevant callback with the resource properties and options, having new properties and options returned that are then passed to the next relevant transform callback until all have been called and the engine has the final resource state and options to use. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [x] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-02-21 16:30:46 +00:00
file_pulumi_resource_proto_msgTypes[9].OneofWrappers = []interface{}{}
type x struct{}
out := protoimpl.TypeBuilder{
File: protoimpl.DescBuilder{
GoPackagePath: reflect.TypeOf(x{}).PkgPath(),
RawDescriptor: file_pulumi_resource_proto_rawDesc,
NumEnums: 1,
Initial work for parameterized providers (#16281) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This is the first part of paramaterized providers in the engine. This only supports "replacement" packages, that is where we fully replace a providers package with a new package (think how dynamic tfbridge will work, vs how crd2pulumi will work). I've made the decision to _not_ support using parameterised providers by sending the parameter in the RegisterResource request. This will necessitate some different work in how we send the parameter for explicit providers compared to version and pluginDownloadURL, but I think it's worth it going forward. No changelog as this is still basically unusable without codegen support done, and should still be considered primarily for internal experimental use for now. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2024-06-10 17:28:47 +00:00
NumMessages: 30,
NumExtensions: 0,
NumServices: 1,
},
GoTypes: file_pulumi_resource_proto_goTypes,
DependencyIndexes: file_pulumi_resource_proto_depIdxs,
EnumInfos: file_pulumi_resource_proto_enumTypes,
MessageInfos: file_pulumi_resource_proto_msgTypes,
}.Build()
File_pulumi_resource_proto = out.File
file_pulumi_resource_proto_rawDesc = nil
file_pulumi_resource_proto_goTypes = nil
file_pulumi_resource_proto_depIdxs = nil
2020-02-28 11:53:47 +00:00
}