maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
pulumi/sdk/nodejs/proto/provider_pb.js

7932 lines
233 KiB
JavaScript
Raw Permalink Normal View History

Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
// source: provider.proto
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
/**
* @fileoverview
* @enhanceable
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {messageConventions} JS Compiler reports an error if a variable or
* field starts with 'MSG_' and isn't a translatable message.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @public
*/
// GENERATED CODE -- DO NOT EDIT!
var jspb = require('google-protobuf');
var goog = jspb;
Work around commonjs protoc bug (#2403) * Work around commonjs protoc bug When compiling with the commonjs target, the protoc compiler still emits references to Closure Compiler-isms that whack global state onto the global object. This is particularly bad for us since we expect to be able to make backwards-compatible changes to our Protobuf definitions without breaking things, and this bug makes it impossible to do so. To remedy the bug, this commit hacks the output of protoc (again) with sed in order to avoid ever touching the global object. Everything still works fine because the commonjs target (correctly) exports the protobuf message types via the module system - it's just not writing to global anymore. * Fix status.proto * Don't hack status.proto
2019-01-30 02:07:47 +01:00
var proto = { pulumirpc: {} }, global = proto;
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
Add a manifest to checkpoint files (#630) This change adds a new manifest section to the checkpoint files. The existing time moves into it, and we add to it the version of the Pulumi CLI that created it, along with the names, types, and versions of all plugins used to generate the file. There is a magic cookie that we also use during verification. This is to help keep us sane when debugging problems "in the wild," and I'm sure we will add more to it over time (checksum, etc). For example, after an up, you can now see this in `pulumi stack`: ``` Current stack is demo: Last updated at 2017-12-01 13:48:49.815740523 -0800 PST Pulumi version v0.8.3-79-g1ab99ad Plugin pulumi-provider-aws [resource] version v0.8.3-22-g4363e77 Plugin pulumi-langhost-nodejs [language] version v0.8.3-79-g77bb6b6 Checkpoint file is /Users/joeduffy/dev/code/src/github.com/pulumi/pulumi-aws/.pulumi/stacks/webserver/demo.json ``` This addresses pulumi/pulumi#628.
2017-12-01 22:50:32 +01:00
var plugin_pb = require('./plugin_pb.js');
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
goog.object.extend(proto, plugin_pb);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var google_protobuf_empty_pb = require('google-protobuf/google/protobuf/empty_pb.js');
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
goog.object.extend(proto, google_protobuf_empty_pb);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var google_protobuf_struct_pb = require('google-protobuf/google/protobuf/struct_pb.js');
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
goog.object.extend(proto, google_protobuf_struct_pb);
Initial support for resource methods (authoring from Node.js, calling from Python) (#7363) Adds initial support for resource methods (via a new `Call` gRPC method similar to `Invoke`), with support for authoring methods from Node.js, and calling methods from Python.
2021-06-30 16:48:56 +02:00
goog.exportSymbol('proto.pulumirpc.CallRequest', null, global);
goog.exportSymbol('proto.pulumirpc.CallRequest.ArgumentDependencies', null, global);
goog.exportSymbol('proto.pulumirpc.CallResponse', null, global);
goog.exportSymbol('proto.pulumirpc.CallResponse.ReturnDependencies', null, global);
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
goog.exportSymbol('proto.pulumirpc.CheckFailure', null, global);
goog.exportSymbol('proto.pulumirpc.CheckRequest', null, global);
goog.exportSymbol('proto.pulumirpc.CheckResponse', null, global);
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
goog.exportSymbol('proto.pulumirpc.ConfigureErrorMissingKeys', null, global);
goog.exportSymbol('proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey', null, global);
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
goog.exportSymbol('proto.pulumirpc.ConfigureRequest', null, global);
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
goog.exportSymbol('proto.pulumirpc.ConfigureResponse', null, global);
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 04:33:55 +02:00
goog.exportSymbol('proto.pulumirpc.ConstructRequest', null, global);
goog.exportSymbol('proto.pulumirpc.ConstructRequest.PropertyDependencies', null, global);
goog.exportSymbol('proto.pulumirpc.ConstructResponse', null, global);
goog.exportSymbol('proto.pulumirpc.ConstructResponse.PropertyDependencies', null, global);
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
goog.exportSymbol('proto.pulumirpc.CreateRequest', null, global);
goog.exportSymbol('proto.pulumirpc.CreateResponse', null, global);
goog.exportSymbol('proto.pulumirpc.DeleteRequest', null, global);
goog.exportSymbol('proto.pulumirpc.DiffRequest', null, global);
goog.exportSymbol('proto.pulumirpc.DiffResponse', null, global);
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
goog.exportSymbol('proto.pulumirpc.DiffResponse.DiffChanges', null, global);
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
goog.exportSymbol('proto.pulumirpc.ErrorResourceInitFailed', null, global);
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
goog.exportSymbol('proto.pulumirpc.GetSchemaRequest', null, global);
goog.exportSymbol('proto.pulumirpc.GetSchemaResponse', null, global);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
goog.exportSymbol('proto.pulumirpc.InvokeRequest', null, global);
goog.exportSymbol('proto.pulumirpc.InvokeResponse', null, global);
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
goog.exportSymbol('proto.pulumirpc.PropertyDiff', null, global);
goog.exportSymbol('proto.pulumirpc.PropertyDiff.Kind', null, global);
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
goog.exportSymbol('proto.pulumirpc.ReadRequest', null, global);
goog.exportSymbol('proto.pulumirpc.ReadResponse', null, global);
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
goog.exportSymbol('proto.pulumirpc.UpdateRequest', null, global);
goog.exportSymbol('proto.pulumirpc.UpdateResponse', null, global);
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.GetSchemaRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.GetSchemaRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @public
* @override
*/
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
proto.pulumirpc.GetSchemaRequest.displayName = 'proto.pulumirpc.GetSchemaRequest';
}
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.GetSchemaResponse = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.GetSchemaResponse, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.GetSchemaResponse.displayName = 'proto.pulumirpc.GetSchemaResponse';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ConfigureRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.ConfigureRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ConfigureRequest.displayName = 'proto.pulumirpc.ConfigureRequest';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ConfigureResponse = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.ConfigureResponse, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ConfigureResponse.displayName = 'proto.pulumirpc.ConfigureResponse';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ConfigureErrorMissingKeys = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.ConfigureErrorMissingKeys.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.ConfigureErrorMissingKeys, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ConfigureErrorMissingKeys.displayName = 'proto.pulumirpc.ConfigureErrorMissingKeys';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.displayName = 'proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.InvokeRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.InvokeRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.InvokeRequest.displayName = 'proto.pulumirpc.InvokeRequest';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.InvokeResponse = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.InvokeResponse.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.InvokeResponse, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.InvokeResponse.displayName = 'proto.pulumirpc.InvokeResponse';
}
Initial support for resource methods (authoring from Node.js, calling from Python) (#7363) Adds initial support for resource methods (via a new `Call` gRPC method similar to `Invoke`), with support for authoring methods from Node.js, and calling methods from Python.
2021-06-30 16:48:56 +02:00
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.CallRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.CallRequest.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.CallRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.CallRequest.displayName = 'proto.pulumirpc.CallRequest';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.CallRequest.ArgumentDependencies = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.CallRequest.ArgumentDependencies.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.CallRequest.ArgumentDependencies, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.displayName = 'proto.pulumirpc.CallRequest.ArgumentDependencies';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.CallResponse = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.CallResponse.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.CallResponse, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.CallResponse.displayName = 'proto.pulumirpc.CallResponse';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.CallResponse.ReturnDependencies = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.CallResponse.ReturnDependencies.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.CallResponse.ReturnDependencies, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.CallResponse.ReturnDependencies.displayName = 'proto.pulumirpc.CallResponse.ReturnDependencies';
}
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.CheckRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.CheckRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.CheckRequest.displayName = 'proto.pulumirpc.CheckRequest';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.CheckResponse = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.CheckResponse.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.CheckResponse, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.CheckResponse.displayName = 'proto.pulumirpc.CheckResponse';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.CheckFailure = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.CheckFailure, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.CheckFailure.displayName = 'proto.pulumirpc.CheckFailure';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.DiffRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.DiffRequest.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.DiffRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.DiffRequest.displayName = 'proto.pulumirpc.DiffRequest';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.PropertyDiff = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.PropertyDiff, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.PropertyDiff.displayName = 'proto.pulumirpc.PropertyDiff';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.DiffResponse = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.DiffResponse.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.DiffResponse, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.DiffResponse.displayName = 'proto.pulumirpc.DiffResponse';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.CreateRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.CreateRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.CreateRequest.displayName = 'proto.pulumirpc.CreateRequest';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.CreateResponse = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.CreateResponse, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.CreateResponse.displayName = 'proto.pulumirpc.CreateResponse';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ReadRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.ReadRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ReadRequest.displayName = 'proto.pulumirpc.ReadRequest';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ReadResponse = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.ReadResponse, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ReadResponse.displayName = 'proto.pulumirpc.ReadResponse';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.UpdateRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.UpdateRequest.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.UpdateRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.UpdateRequest.displayName = 'proto.pulumirpc.UpdateRequest';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.UpdateResponse = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.UpdateResponse, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.UpdateResponse.displayName = 'proto.pulumirpc.UpdateResponse';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.DeleteRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.DeleteRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.DeleteRequest.displayName = 'proto.pulumirpc.DeleteRequest';
}
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 04:33:55 +02:00
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ConstructRequest = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.ConstructRequest.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.ConstructRequest, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ConstructRequest.displayName = 'proto.pulumirpc.ConstructRequest';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.ConstructRequest.PropertyDependencies.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.ConstructRequest.PropertyDependencies, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.displayName = 'proto.pulumirpc.ConstructRequest.PropertyDependencies';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ConstructResponse = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.pulumirpc.ConstructResponse, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ConstructResponse.displayName = 'proto.pulumirpc.ConstructResponse';
}
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.ConstructResponse.PropertyDependencies.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.ConstructResponse.PropertyDependencies, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.displayName = 'proto.pulumirpc.ConstructResponse.PropertyDependencies';
}
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Generated by JsPbCodeGenerator.
* @param {Array=} opt_data Optional initial data array, typically from a
* server response, or constructed directly in Javascript. The array is used
* in place and becomes part of the constructed object. It is not cloned.
* If no data is provided, the constructed object will be empty, but still
* valid.
* @extends {jspb.Message}
* @constructor
*/
proto.pulumirpc.ErrorResourceInitFailed = function(opt_data) {
jspb.Message.initialize(this, opt_data, 0, -1, proto.pulumirpc.ErrorResourceInitFailed.repeatedFields_, null);
};
goog.inherits(proto.pulumirpc.ErrorResourceInitFailed, jspb.Message);
if (goog.DEBUG && !COMPILED) {
/**
* @public
* @override
*/
proto.pulumirpc.ErrorResourceInitFailed.displayName = 'proto.pulumirpc.ErrorResourceInitFailed';
}
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
* @return {!Object}
*/
proto.pulumirpc.GetSchemaRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.GetSchemaRequest.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.GetSchemaRequest} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.GetSchemaRequest.toObject = function(includeInstance, msg) {
var f, obj = {
version: jspb.Message.getFieldWithDefault(msg, 1, 0)
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.GetSchemaRequest}
*/
proto.pulumirpc.GetSchemaRequest.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.GetSchemaRequest;
return proto.pulumirpc.GetSchemaRequest.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.GetSchemaRequest} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.GetSchemaRequest}
*/
proto.pulumirpc.GetSchemaRequest.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {number} */ (reader.readInt32());
msg.setVersion(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.GetSchemaRequest.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.GetSchemaRequest.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.GetSchemaRequest} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.GetSchemaRequest.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getVersion();
if (f !== 0) {
writer.writeInt32(
1,
f
);
}
};
/**
* optional int32 version = 1;
* @return {number}
*/
proto.pulumirpc.GetSchemaRequest.prototype.getVersion = function() {
return /** @type {number} */ (jspb.Message.getFieldWithDefault(this, 1, 0));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {number} value
* @return {!proto.pulumirpc.GetSchemaRequest} returns this
*/
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
proto.pulumirpc.GetSchemaRequest.prototype.setVersion = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3IntField(this, 1, value);
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
};
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
* @return {!Object}
*/
proto.pulumirpc.GetSchemaResponse.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.GetSchemaResponse.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.GetSchemaResponse} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.GetSchemaResponse.toObject = function(includeInstance, msg) {
var f, obj = {
schema: jspb.Message.getFieldWithDefault(msg, 1, "")
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.GetSchemaResponse}
*/
proto.pulumirpc.GetSchemaResponse.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.GetSchemaResponse;
return proto.pulumirpc.GetSchemaResponse.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.GetSchemaResponse} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.GetSchemaResponse}
*/
proto.pulumirpc.GetSchemaResponse.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.setSchema(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.GetSchemaResponse.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.GetSchemaResponse.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.GetSchemaResponse} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.GetSchemaResponse.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getSchema();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
};
/**
* optional string schema = 1;
* @return {string}
*/
proto.pulumirpc.GetSchemaResponse.prototype.getSchema = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.GetSchemaResponse} returns this
*/
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
proto.pulumirpc.GetSchemaResponse.prototype.setSchema = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Add support for extracting schemas from providers. (#3984) These changes add a new method to the resource provider gRPC interface, `GetSchema`, that allows consumers of these providers to extract JSON-serialized schema information for the provider's types, resources, and functions.
2020-02-28 01:10:47 +01:00
};
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
* @return {!Object}
*/
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.ConfigureRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ConfigureRequest.toObject(opt_includeInstance, this);
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
* http://goto/soy-param-migration
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
* @param {!proto.pulumirpc.ConfigureRequest} msg The msg instance to transform.
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
*/
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.ConfigureRequest.toObject = function(includeInstance, msg) {
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
var f, obj = {
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
variablesMap: (f = msg.getVariablesMap()) ? f.toObject(includeInstance, undefined) : [],
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
args: (f = msg.getArgs()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
acceptsecrets: jspb.Message.getBooleanFieldWithDefault(msg, 3, false),
acceptresources: jspb.Message.getBooleanFieldWithDefault(msg, 4, false)
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
* @return {!proto.pulumirpc.ConfigureRequest}
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
*/
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.ConfigureRequest.deserializeBinary = function(bytes) {
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
var reader = new jspb.BinaryReader(bytes);
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
var msg = new proto.pulumirpc.ConfigureRequest;
return proto.pulumirpc.ConfigureRequest.deserializeBinaryFromReader(msg, reader);
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
* @param {!proto.pulumirpc.ConfigureRequest} msg The message object to deserialize into.
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
* @return {!proto.pulumirpc.ConfigureRequest}
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
*/
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.ConfigureRequest.deserializeBinaryFromReader = function(msg, reader) {
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = msg.getVariablesMap();
reader.readMessage(value, function(message, reader) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
jspb.Map.deserializeBinary(message, reader, jspb.BinaryReader.prototype.readString, jspb.BinaryReader.prototype.readString, null, "", "");
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
});
break;
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
case 2:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setArgs(value);
break;
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
case 3:
var value = /** @type {boolean} */ (reader.readBool());
msg.setAcceptsecrets(value);
break;
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
case 4:
var value = /** @type {boolean} */ (reader.readBool());
msg.setAcceptresources(value);
break;
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.ConfigureRequest.prototype.serializeBinary = function() {
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
var writer = new jspb.BinaryWriter();
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.ConfigureRequest.serializeBinaryToWriter(this, writer);
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
* @param {!proto.pulumirpc.ConfigureRequest} message
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
*/
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.ConfigureRequest.serializeBinaryToWriter = function(message, writer) {
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
var f = undefined;
f = message.getVariablesMap(true);
if (f && f.getLength() > 0) {
f.serializeBinary(1, writer, jspb.BinaryWriter.prototype.writeString, jspb.BinaryWriter.prototype.writeString);
}
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
f = message.getArgs();
if (f != null) {
writer.writeMessage(
2,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
f = message.getAcceptsecrets();
if (f) {
writer.writeBool(
3,
f
);
}
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
f = message.getAcceptresources();
if (f) {
writer.writeBool(
4,
f
);
}
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
};
/**
* map<string, string> variables = 1;
* @param {boolean=} opt_noLazyCreate Do not create the map if
* empty, instead returning `undefined`
* @return {!jspb.Map<string,string>}
*/
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.ConfigureRequest.prototype.getVariablesMap = function(opt_noLazyCreate) {
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
return /** @type {!jspb.Map<string,string>} */ (
jspb.Message.getMapField(this, 1, opt_noLazyCreate,
null));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears values from the map. The map will be non-null.
* @return {!proto.pulumirpc.ConfigureRequest} returns this
*/
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.ConfigureRequest.prototype.clearVariablesMap = function() {
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
this.getVariablesMap().clear();
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this;};
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
/**
* optional google.protobuf.Struct args = 2;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.ConfigureRequest.prototype.getArgs = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 2));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.ConfigureRequest} returns this
*/
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
proto.pulumirpc.ConfigureRequest.prototype.setArgs = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 2, value);
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.ConfigureRequest} returns this
*/
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
proto.pulumirpc.ConfigureRequest.prototype.clearArgs = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setArgs(undefined);
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
*/
proto.pulumirpc.ConfigureRequest.prototype.hasArgs = function() {
return jspb.Message.getField(this, 2) != null;
};
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
/**
* optional bool acceptSecrets = 3;
* @return {boolean}
*/
proto.pulumirpc.ConfigureRequest.prototype.getAcceptsecrets = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 3, false));
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {boolean} value
* @return {!proto.pulumirpc.ConfigureRequest} returns this
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
*/
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
proto.pulumirpc.ConfigureRequest.prototype.setAcceptsecrets = function(value) {
return jspb.Message.setProto3BooleanField(this, 3, value);
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
/**
* optional bool acceptResources = 4;
* @return {boolean}
*/
proto.pulumirpc.ConfigureRequest.prototype.getAcceptresources = function() {
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 4, false));
};
/**
* @param {boolean} value
* @return {!proto.pulumirpc.ConfigureRequest} returns this
*/
proto.pulumirpc.ConfigureRequest.prototype.setAcceptresources = function(value) {
return jspb.Message.setProto3BooleanField(this, 4, value);
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
* @return {!Object}
*/
proto.pulumirpc.ConfigureResponse.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ConfigureResponse.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.ConfigureResponse} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConfigureResponse.toObject = function(includeInstance, msg) {
var f, obj = {
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
acceptsecrets: jspb.Message.getBooleanFieldWithDefault(msg, 1, false),
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
supportspreview: jspb.Message.getBooleanFieldWithDefault(msg, 2, false),
Add monitor feature for output values (#7870)
2021-09-15 23:16:00 +02:00
acceptresources: jspb.Message.getBooleanFieldWithDefault(msg, 3, false),
acceptoutputs: jspb.Message.getBooleanFieldWithDefault(msg, 4, false)
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.ConfigureResponse}
*/
proto.pulumirpc.ConfigureResponse.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.ConfigureResponse;
return proto.pulumirpc.ConfigureResponse.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.ConfigureResponse} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.ConfigureResponse}
*/
proto.pulumirpc.ConfigureResponse.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {boolean} */ (reader.readBool());
msg.setAcceptsecrets(value);
break;
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
case 2:
var value = /** @type {boolean} */ (reader.readBool());
msg.setSupportspreview(value);
break;
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
case 3:
var value = /** @type {boolean} */ (reader.readBool());
msg.setAcceptresources(value);
break;
Add monitor feature for output values (#7870)
2021-09-15 23:16:00 +02:00
case 4:
var value = /** @type {boolean} */ (reader.readBool());
msg.setAcceptoutputs(value);
break;
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.ConfigureResponse.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.ConfigureResponse.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.ConfigureResponse} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConfigureResponse.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getAcceptsecrets();
if (f) {
writer.writeBool(
1,
f
);
}
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
f = message.getSupportspreview();
if (f) {
writer.writeBool(
2,
f
);
}
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
f = message.getAcceptresources();
if (f) {
writer.writeBool(
3,
f
);
}
Add monitor feature for output values (#7870)
2021-09-15 23:16:00 +02:00
f = message.getAcceptoutputs();
if (f) {
writer.writeBool(
4,
f
);
}
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
};
/**
* optional bool acceptSecrets = 1;
* @return {boolean}
*/
proto.pulumirpc.ConfigureResponse.prototype.getAcceptsecrets = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 1, false));
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {boolean} value
* @return {!proto.pulumirpc.ConfigureResponse} returns this
*/
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
proto.pulumirpc.ConfigureResponse.prototype.setAcceptsecrets = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3BooleanField(this, 1, value);
Regnerate gRPC generated code
2019-04-12 20:27:18 +02:00
};
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
/**
* optional bool supportsPreview = 2;
* @return {boolean}
*/
proto.pulumirpc.ConfigureResponse.prototype.getSupportspreview = function() {
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 2, false));
};
/**
* @param {boolean} value
* @return {!proto.pulumirpc.ConfigureResponse} returns this
*/
proto.pulumirpc.ConfigureResponse.prototype.setSupportspreview = function(value) {
return jspb.Message.setProto3BooleanField(this, 2, value);
};
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
/**
* optional bool acceptResources = 3;
* @return {boolean}
*/
proto.pulumirpc.ConfigureResponse.prototype.getAcceptresources = function() {
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 3, false));
};
/**
* @param {boolean} value
* @return {!proto.pulumirpc.ConfigureResponse} returns this
*/
proto.pulumirpc.ConfigureResponse.prototype.setAcceptresources = function(value) {
return jspb.Message.setProto3BooleanField(this, 3, value);
};
Add monitor feature for output values (#7870)
2021-09-15 23:16:00 +02:00
/**
* optional bool acceptOutputs = 4;
* @return {boolean}
*/
proto.pulumirpc.ConfigureResponse.prototype.getAcceptoutputs = function() {
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 4, false));
};
/**
* @param {boolean} value
* @return {!proto.pulumirpc.ConfigureResponse} returns this
*/
proto.pulumirpc.ConfigureResponse.prototype.setAcceptoutputs = function(value) {
return jspb.Message.setProto3BooleanField(this, 4, value);
};
Configure providers at well-defined points As explained in pulumi/pulumi-fabric#293, we were a little ad-hoc in how configuration was "applied" to resource providers. In fact, config wasn't ever communicated directly to providers; instead, the resource providers would simply ask the engine to read random heap locations (via tokens). Now that we're on a plan where configuration gets handed to the program at startup, and that's that, and where generally speaking resource providers never communicate directly with the language runtime, we need to take a different approach. As such, the resource provider interface now offers a Configure RPC method that the resource planning engine will invoke at the right times with the right subset of configuration variables filtered to just that provider's package. This fixes pulumi/pulumi#293.
2017-08-31 23:31:33 +02:00
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.ConfigureErrorMissingKeys.repeatedFields_ = [1];
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
* @return {!Object}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ConfigureErrorMissingKeys.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.ConfigureErrorMissingKeys} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConfigureErrorMissingKeys.toObject = function(includeInstance, msg) {
var f, obj = {
missingkeysList: jspb.Message.toObjectList(msg.getMissingkeysList(),
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.toObject, includeInstance)
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.ConfigureErrorMissingKeys}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.ConfigureErrorMissingKeys;
return proto.pulumirpc.ConfigureErrorMissingKeys.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.ConfigureErrorMissingKeys} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.ConfigureErrorMissingKeys}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = new proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey;
reader.readMessage(value,proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.deserializeBinaryFromReader);
msg.addMissingkeys(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.ConfigureErrorMissingKeys.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.ConfigureErrorMissingKeys} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConfigureErrorMissingKeys.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getMissingkeysList();
if (f.length > 0) {
writer.writeRepeatedMessage(
1,
f,
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.serializeBinaryToWriter
);
}
};
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
* @return {!Object}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.toObject = function(includeInstance, msg) {
var f, obj = {
name: jspb.Message.getFieldWithDefault(msg, 1, ""),
description: jspb.Message.getFieldWithDefault(msg, 2, "")
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey;
return proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.setName(value);
break;
case 2:
var value = /** @type {string} */ (reader.readString());
msg.setDescription(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getName();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
f = message.getDescription();
if (f.length > 0) {
writer.writeString(
2,
f
);
}
};
/**
* optional string name = 1;
* @return {string}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.prototype.getName = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey} returns this
*/
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.prototype.setName = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
};
/**
* optional string description = 2;
* @return {string}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.prototype.getDescription = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 2, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey} returns this
*/
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey.prototype.setDescription = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 2, value);
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
};
/**
* repeated MissingKey missingKeys = 1;
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!Array<!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey>}
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
*/
proto.pulumirpc.ConfigureErrorMissingKeys.prototype.getMissingkeysList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type{!Array<!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey>} */ (
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
jspb.Message.getRepeatedWrapperField(this, proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey, 1));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!Array<!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey>} value
* @return {!proto.pulumirpc.ConfigureErrorMissingKeys} returns this
*/
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
proto.pulumirpc.ConfigureErrorMissingKeys.prototype.setMissingkeysList = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setRepeatedWrapperField(this, 1, value);
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
};
/**
* @param {!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey=} opt_value
* @param {number=} opt_index
* @return {!proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey}
*/
proto.pulumirpc.ConfigureErrorMissingKeys.prototype.addMissingkeys = function(opt_value, opt_index) {
return jspb.Message.addToRepeatedWrapperField(this, 1, opt_value, proto.pulumirpc.ConfigureErrorMissingKeys.MissingKey, opt_index);
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.ConfigureErrorMissingKeys} returns this
*/
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
proto.pulumirpc.ConfigureErrorMissingKeys.prototype.clearMissingkeysList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setMissingkeysList([]);
Improve the error message arising from missing required configs for resource providers (#1097) * Improve the error message arising from missing required configs for resource providers If the resource provider that we are speaking to is new enough, it will send across a list of keys and their descriptions alongside an error indicating that the provider we are configuring is missing required config. This commit packages up the list of missing keys into an error that can be presented nicely to the user. * Code review feedback: renaming simplification and correcting errors in comments
2018-04-04 19:08:17 +02:00
};
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.InvokeRequest.toObject(opt_includeInstance, this);
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.InvokeRequest} msg The msg instance to transform.
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.toObject = function(includeInstance, msg) {
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
var f, obj = {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
tok: jspb.Message.getFieldWithDefault(msg, 1, ""),
Implement first-class providers. (#1695) ### First-Class Providers These changes implement support for first-class providers. First-class providers are provider plugins that are exposed as resources via the Pulumi programming model so that they may be explicitly and multiply instantiated. Each instance of a provider resource may be configured differently, and configuration parameters may be source from the outputs of other resources. ### Provider Plugin Changes In order to accommodate the need to verify and diff provider configuration and configure providers without complete configuration information, these changes adjust the high-level provider plugin interface. Two new methods for validating a provider's configuration and diffing changes to the same have been added (`CheckConfig` and `DiffConfig`, respectively), and the type of the configuration bag accepted by `Configure` has been changed to a `PropertyMap`. These changes have not yet been reflected in the provider plugin gRPC interface. We will do this in a set of follow-up changes. Until then, these methods are implemented by adapters: - `CheckConfig` validates that all configuration parameters are string or unknown properties. This is necessary because existing plugins only accept string-typed configuration values. - `DiffConfig` either returns "never replace" if all configuration values are known or "must replace" if any configuration value is unknown. The justification for this behavior is given [here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106) - `Configure` converts the config bag to a legacy config map and configures the provider plugin if all config values are known. If any config value is unknown, the underlying plugin is not configured and the provider may only perform `Check`, `Read`, and `Invoke`, all of which return empty results. We justify this behavior becuase it is only possible during a preview and provides the best experience we can manage with the existing gRPC interface. ### Resource Model Changes Providers are now exposed as resources that participate in a stack's dependency graph. Like other resources, they are explicitly created, may have multiple instances, and may have dependencies on other resources. Providers are referred to using provider references, which are a combination of the provider's URN and its ID. This design addresses the need during a preview to refer to providers that have not yet been physically created and therefore have no ID. All custom resources that are not themselves providers must specify a single provider via a provider reference. The named provider will be used to manage that resource's CRUD operations. If a resource's provider reference changes, the resource must be replaced. Though its URN is not present in the resource's dependency list, the provider should be treated as a dependency of the resource when topologically sorting the dependency graph. Finally, `Invoke` operations must now specify a provider to use for the invocation via a provider reference. ### Engine Changes First-class providers support requires a few changes to the engine: - The engine must have some way to map from provider references to provider plugins. It must be possible to add providers from a stack's checkpoint to this map and to register new/updated providers during the execution of a plan in response to CRUD operations on provider resources. - In order to support updating existing stacks using existing Pulumi programs that may not explicitly instantiate providers, the engine must be able to manage the "default" providers for each package referenced by a checkpoint or Pulumi program. The configuration for a "default" provider is taken from the stack's configuration data. The former need is addressed by adding a provider registry type that is responsible for managing all of the plugins required by a plan. In addition to loading plugins froma checkpoint and providing the ability to map from a provider reference to a provider plugin, this type serves as the provider plugin for providers themselves (i.e. it is the "provider provider"). The latter need is solved via two relatively self-contained changes to plan setup and the eval source. During plan setup, the old checkpoint is scanned for custom resources that do not have a provider reference in order to compute the set of packages that require a default provider. Once this set has been computed, the required default provider definitions are conjured and prepended to the checkpoint's resource list. Each resource that requires a default provider is then updated to refer to the default provider for its package. While an eval source is running, each custom resource registration, resource read, and invoke that does not name a provider is trapped before being returned by the source iterator. If no default provider for the appropriate package has been registered, the eval source synthesizes an appropriate registration, waits for it to complete, and records the registered provider's reference. This reference is injected into the original request, which is then processed as usual. If a default provider was already registered, the recorded reference is used and no new registration occurs. ### SDK Changes These changes only expose first-class providers from the Node.JS SDK. - A new abstract class, `ProviderResource`, can be subclassed and used to instantiate first-class providers. - A new field in `ResourceOptions`, `provider`, can be used to supply a particular provider instance to manage a `CustomResource`'s CRUD operations. - A new type, `InvokeOptions`, can be used to specify options that control the behavior of a call to `pulumi.runtime.invoke`. This type includes a `provider` field that is analogous to `ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
args: (f = msg.getArgs()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Protobuf changes for provider versioning (#2642) In pursuit of pulumi/pulumi#2389, this commit adds the necessary changes to the resource monitor protocol so that language hosts can communicate exactly what version of a provider should be used when servicing an Invoke, ReadResource, or RegisterResource. The expectation here is that, if a language host provides a version, the engine MUST use EXACTLY that version of a provider plugin in order to service the request.
2019-04-16 19:06:43 +02:00
provider: jspb.Message.getFieldWithDefault(msg, 3, ""),
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
version: jspb.Message.getFieldWithDefault(msg, 4, ""),
acceptresources: jspb.Message.getBooleanFieldWithDefault(msg, 5, false)
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.InvokeRequest}
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.deserializeBinary = function(bytes) {
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.InvokeRequest;
return proto.pulumirpc.InvokeRequest.deserializeBinaryFromReader(msg, reader);
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.InvokeRequest} msg The message object to deserialize into.
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.InvokeRequest}
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.deserializeBinaryFromReader = function(msg, reader) {
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.setTok(value);
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
break;
case 2:
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.setArgs(value);
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
break;
Implement first-class providers. (#1695) ### First-Class Providers These changes implement support for first-class providers. First-class providers are provider plugins that are exposed as resources via the Pulumi programming model so that they may be explicitly and multiply instantiated. Each instance of a provider resource may be configured differently, and configuration parameters may be source from the outputs of other resources. ### Provider Plugin Changes In order to accommodate the need to verify and diff provider configuration and configure providers without complete configuration information, these changes adjust the high-level provider plugin interface. Two new methods for validating a provider's configuration and diffing changes to the same have been added (`CheckConfig` and `DiffConfig`, respectively), and the type of the configuration bag accepted by `Configure` has been changed to a `PropertyMap`. These changes have not yet been reflected in the provider plugin gRPC interface. We will do this in a set of follow-up changes. Until then, these methods are implemented by adapters: - `CheckConfig` validates that all configuration parameters are string or unknown properties. This is necessary because existing plugins only accept string-typed configuration values. - `DiffConfig` either returns "never replace" if all configuration values are known or "must replace" if any configuration value is unknown. The justification for this behavior is given [here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106) - `Configure` converts the config bag to a legacy config map and configures the provider plugin if all config values are known. If any config value is unknown, the underlying plugin is not configured and the provider may only perform `Check`, `Read`, and `Invoke`, all of which return empty results. We justify this behavior becuase it is only possible during a preview and provides the best experience we can manage with the existing gRPC interface. ### Resource Model Changes Providers are now exposed as resources that participate in a stack's dependency graph. Like other resources, they are explicitly created, may have multiple instances, and may have dependencies on other resources. Providers are referred to using provider references, which are a combination of the provider's URN and its ID. This design addresses the need during a preview to refer to providers that have not yet been physically created and therefore have no ID. All custom resources that are not themselves providers must specify a single provider via a provider reference. The named provider will be used to manage that resource's CRUD operations. If a resource's provider reference changes, the resource must be replaced. Though its URN is not present in the resource's dependency list, the provider should be treated as a dependency of the resource when topologically sorting the dependency graph. Finally, `Invoke` operations must now specify a provider to use for the invocation via a provider reference. ### Engine Changes First-class providers support requires a few changes to the engine: - The engine must have some way to map from provider references to provider plugins. It must be possible to add providers from a stack's checkpoint to this map and to register new/updated providers during the execution of a plan in response to CRUD operations on provider resources. - In order to support updating existing stacks using existing Pulumi programs that may not explicitly instantiate providers, the engine must be able to manage the "default" providers for each package referenced by a checkpoint or Pulumi program. The configuration for a "default" provider is taken from the stack's configuration data. The former need is addressed by adding a provider registry type that is responsible for managing all of the plugins required by a plan. In addition to loading plugins froma checkpoint and providing the ability to map from a provider reference to a provider plugin, this type serves as the provider plugin for providers themselves (i.e. it is the "provider provider"). The latter need is solved via two relatively self-contained changes to plan setup and the eval source. During plan setup, the old checkpoint is scanned for custom resources that do not have a provider reference in order to compute the set of packages that require a default provider. Once this set has been computed, the required default provider definitions are conjured and prepended to the checkpoint's resource list. Each resource that requires a default provider is then updated to refer to the default provider for its package. While an eval source is running, each custom resource registration, resource read, and invoke that does not name a provider is trapped before being returned by the source iterator. If no default provider for the appropriate package has been registered, the eval source synthesizes an appropriate registration, waits for it to complete, and records the registered provider's reference. This reference is injected into the original request, which is then processed as usual. If a default provider was already registered, the recorded reference is used and no new registration occurs. ### SDK Changes These changes only expose first-class providers from the Node.JS SDK. - A new abstract class, `ProviderResource`, can be subclassed and used to instantiate first-class providers. - A new field in `ResourceOptions`, `provider`, can be used to supply a particular provider instance to manage a `CustomResource`'s CRUD operations. - A new type, `InvokeOptions`, can be used to specify options that control the behavior of a call to `pulumi.runtime.invoke`. This type includes a `provider` field that is analogous to `ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
case 3:
var value = /** @type {string} */ (reader.readString());
msg.setProvider(value);
break;
Protobuf changes for provider versioning (#2642) In pursuit of pulumi/pulumi#2389, this commit adds the necessary changes to the resource monitor protocol so that language hosts can communicate exactly what version of a provider should be used when servicing an Invoke, ReadResource, or RegisterResource. The expectation here is that, if a language host provides a version, the engine MUST use EXACTLY that version of a provider plugin in order to service the request.
2019-04-16 19:06:43 +02:00
case 4:
var value = /** @type {string} */ (reader.readString());
msg.setVersion(value);
break;
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
case 5:
var value = /** @type {boolean} */ (reader.readBool());
msg.setAcceptresources(value);
break;
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.prototype.serializeBinary = function() {
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.serializeBinaryToWriter(this, writer);
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.InvokeRequest} message
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.serializeBinaryToWriter = function(message, writer) {
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
var f = undefined;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getTok();
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
if (f.length > 0) {
writer.writeString(
1,
f
);
}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getArgs();
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
if (f != null) {
writer.writeMessage(
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
2,
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
);
}
Implement first-class providers. (#1695) ### First-Class Providers These changes implement support for first-class providers. First-class providers are provider plugins that are exposed as resources via the Pulumi programming model so that they may be explicitly and multiply instantiated. Each instance of a provider resource may be configured differently, and configuration parameters may be source from the outputs of other resources. ### Provider Plugin Changes In order to accommodate the need to verify and diff provider configuration and configure providers without complete configuration information, these changes adjust the high-level provider plugin interface. Two new methods for validating a provider's configuration and diffing changes to the same have been added (`CheckConfig` and `DiffConfig`, respectively), and the type of the configuration bag accepted by `Configure` has been changed to a `PropertyMap`. These changes have not yet been reflected in the provider plugin gRPC interface. We will do this in a set of follow-up changes. Until then, these methods are implemented by adapters: - `CheckConfig` validates that all configuration parameters are string or unknown properties. This is necessary because existing plugins only accept string-typed configuration values. - `DiffConfig` either returns "never replace" if all configuration values are known or "must replace" if any configuration value is unknown. The justification for this behavior is given [here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106) - `Configure` converts the config bag to a legacy config map and configures the provider plugin if all config values are known. If any config value is unknown, the underlying plugin is not configured and the provider may only perform `Check`, `Read`, and `Invoke`, all of which return empty results. We justify this behavior becuase it is only possible during a preview and provides the best experience we can manage with the existing gRPC interface. ### Resource Model Changes Providers are now exposed as resources that participate in a stack's dependency graph. Like other resources, they are explicitly created, may have multiple instances, and may have dependencies on other resources. Providers are referred to using provider references, which are a combination of the provider's URN and its ID. This design addresses the need during a preview to refer to providers that have not yet been physically created and therefore have no ID. All custom resources that are not themselves providers must specify a single provider via a provider reference. The named provider will be used to manage that resource's CRUD operations. If a resource's provider reference changes, the resource must be replaced. Though its URN is not present in the resource's dependency list, the provider should be treated as a dependency of the resource when topologically sorting the dependency graph. Finally, `Invoke` operations must now specify a provider to use for the invocation via a provider reference. ### Engine Changes First-class providers support requires a few changes to the engine: - The engine must have some way to map from provider references to provider plugins. It must be possible to add providers from a stack's checkpoint to this map and to register new/updated providers during the execution of a plan in response to CRUD operations on provider resources. - In order to support updating existing stacks using existing Pulumi programs that may not explicitly instantiate providers, the engine must be able to manage the "default" providers for each package referenced by a checkpoint or Pulumi program. The configuration for a "default" provider is taken from the stack's configuration data. The former need is addressed by adding a provider registry type that is responsible for managing all of the plugins required by a plan. In addition to loading plugins froma checkpoint and providing the ability to map from a provider reference to a provider plugin, this type serves as the provider plugin for providers themselves (i.e. it is the "provider provider"). The latter need is solved via two relatively self-contained changes to plan setup and the eval source. During plan setup, the old checkpoint is scanned for custom resources that do not have a provider reference in order to compute the set of packages that require a default provider. Once this set has been computed, the required default provider definitions are conjured and prepended to the checkpoint's resource list. Each resource that requires a default provider is then updated to refer to the default provider for its package. While an eval source is running, each custom resource registration, resource read, and invoke that does not name a provider is trapped before being returned by the source iterator. If no default provider for the appropriate package has been registered, the eval source synthesizes an appropriate registration, waits for it to complete, and records the registered provider's reference. This reference is injected into the original request, which is then processed as usual. If a default provider was already registered, the recorded reference is used and no new registration occurs. ### SDK Changes These changes only expose first-class providers from the Node.JS SDK. - A new abstract class, `ProviderResource`, can be subclassed and used to instantiate first-class providers. - A new field in `ResourceOptions`, `provider`, can be used to supply a particular provider instance to manage a `CustomResource`'s CRUD operations. - A new type, `InvokeOptions`, can be used to specify options that control the behavior of a call to `pulumi.runtime.invoke`. This type includes a `provider` field that is analogous to `ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
f = message.getProvider();
if (f.length > 0) {
writer.writeString(
3,
f
);
}
Protobuf changes for provider versioning (#2642) In pursuit of pulumi/pulumi#2389, this commit adds the necessary changes to the resource monitor protocol so that language hosts can communicate exactly what version of a provider should be used when servicing an Invoke, ReadResource, or RegisterResource. The expectation here is that, if a language host provides a version, the engine MUST use EXACTLY that version of a provider plugin in order to service the request.
2019-04-16 19:06:43 +02:00
f = message.getVersion();
if (f.length > 0) {
writer.writeString(
4,
f
);
}
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
f = message.getAcceptresources();
if (f) {
writer.writeBool(
5,
f
);
}
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional string tok = 1;
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
* @return {string}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.prototype.getTok = function() {
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.InvokeRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.prototype.setTok = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional google.protobuf.Struct args = 2;
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
* @return {?proto.google.protobuf.Struct}
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.prototype.getArgs = function() {
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 2));
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.InvokeRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.prototype.setArgs = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 2, value);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.InvokeRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.prototype.clearArgs = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setArgs(undefined);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeRequest.prototype.hasArgs = function() {
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
return jspb.Message.getField(this, 2) != null;
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
};
Implement first-class providers. (#1695) ### First-Class Providers These changes implement support for first-class providers. First-class providers are provider plugins that are exposed as resources via the Pulumi programming model so that they may be explicitly and multiply instantiated. Each instance of a provider resource may be configured differently, and configuration parameters may be source from the outputs of other resources. ### Provider Plugin Changes In order to accommodate the need to verify and diff provider configuration and configure providers without complete configuration information, these changes adjust the high-level provider plugin interface. Two new methods for validating a provider's configuration and diffing changes to the same have been added (`CheckConfig` and `DiffConfig`, respectively), and the type of the configuration bag accepted by `Configure` has been changed to a `PropertyMap`. These changes have not yet been reflected in the provider plugin gRPC interface. We will do this in a set of follow-up changes. Until then, these methods are implemented by adapters: - `CheckConfig` validates that all configuration parameters are string or unknown properties. This is necessary because existing plugins only accept string-typed configuration values. - `DiffConfig` either returns "never replace" if all configuration values are known or "must replace" if any configuration value is unknown. The justification for this behavior is given [here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106) - `Configure` converts the config bag to a legacy config map and configures the provider plugin if all config values are known. If any config value is unknown, the underlying plugin is not configured and the provider may only perform `Check`, `Read`, and `Invoke`, all of which return empty results. We justify this behavior becuase it is only possible during a preview and provides the best experience we can manage with the existing gRPC interface. ### Resource Model Changes Providers are now exposed as resources that participate in a stack's dependency graph. Like other resources, they are explicitly created, may have multiple instances, and may have dependencies on other resources. Providers are referred to using provider references, which are a combination of the provider's URN and its ID. This design addresses the need during a preview to refer to providers that have not yet been physically created and therefore have no ID. All custom resources that are not themselves providers must specify a single provider via a provider reference. The named provider will be used to manage that resource's CRUD operations. If a resource's provider reference changes, the resource must be replaced. Though its URN is not present in the resource's dependency list, the provider should be treated as a dependency of the resource when topologically sorting the dependency graph. Finally, `Invoke` operations must now specify a provider to use for the invocation via a provider reference. ### Engine Changes First-class providers support requires a few changes to the engine: - The engine must have some way to map from provider references to provider plugins. It must be possible to add providers from a stack's checkpoint to this map and to register new/updated providers during the execution of a plan in response to CRUD operations on provider resources. - In order to support updating existing stacks using existing Pulumi programs that may not explicitly instantiate providers, the engine must be able to manage the "default" providers for each package referenced by a checkpoint or Pulumi program. The configuration for a "default" provider is taken from the stack's configuration data. The former need is addressed by adding a provider registry type that is responsible for managing all of the plugins required by a plan. In addition to loading plugins froma checkpoint and providing the ability to map from a provider reference to a provider plugin, this type serves as the provider plugin for providers themselves (i.e. it is the "provider provider"). The latter need is solved via two relatively self-contained changes to plan setup and the eval source. During plan setup, the old checkpoint is scanned for custom resources that do not have a provider reference in order to compute the set of packages that require a default provider. Once this set has been computed, the required default provider definitions are conjured and prepended to the checkpoint's resource list. Each resource that requires a default provider is then updated to refer to the default provider for its package. While an eval source is running, each custom resource registration, resource read, and invoke that does not name a provider is trapped before being returned by the source iterator. If no default provider for the appropriate package has been registered, the eval source synthesizes an appropriate registration, waits for it to complete, and records the registered provider's reference. This reference is injected into the original request, which is then processed as usual. If a default provider was already registered, the recorded reference is used and no new registration occurs. ### SDK Changes These changes only expose first-class providers from the Node.JS SDK. - A new abstract class, `ProviderResource`, can be subclassed and used to instantiate first-class providers. - A new field in `ResourceOptions`, `provider`, can be used to supply a particular provider instance to manage a `CustomResource`'s CRUD operations. - A new type, `InvokeOptions`, can be used to specify options that control the behavior of a call to `pulumi.runtime.invoke`. This type includes a `provider` field that is analogous to `ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
/**
* optional string provider = 3;
* @return {string}
*/
proto.pulumirpc.InvokeRequest.prototype.getProvider = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 3, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.InvokeRequest} returns this
*/
Implement first-class providers. (#1695) ### First-Class Providers These changes implement support for first-class providers. First-class providers are provider plugins that are exposed as resources via the Pulumi programming model so that they may be explicitly and multiply instantiated. Each instance of a provider resource may be configured differently, and configuration parameters may be source from the outputs of other resources. ### Provider Plugin Changes In order to accommodate the need to verify and diff provider configuration and configure providers without complete configuration information, these changes adjust the high-level provider plugin interface. Two new methods for validating a provider's configuration and diffing changes to the same have been added (`CheckConfig` and `DiffConfig`, respectively), and the type of the configuration bag accepted by `Configure` has been changed to a `PropertyMap`. These changes have not yet been reflected in the provider plugin gRPC interface. We will do this in a set of follow-up changes. Until then, these methods are implemented by adapters: - `CheckConfig` validates that all configuration parameters are string or unknown properties. This is necessary because existing plugins only accept string-typed configuration values. - `DiffConfig` either returns "never replace" if all configuration values are known or "must replace" if any configuration value is unknown. The justification for this behavior is given [here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106) - `Configure` converts the config bag to a legacy config map and configures the provider plugin if all config values are known. If any config value is unknown, the underlying plugin is not configured and the provider may only perform `Check`, `Read`, and `Invoke`, all of which return empty results. We justify this behavior becuase it is only possible during a preview and provides the best experience we can manage with the existing gRPC interface. ### Resource Model Changes Providers are now exposed as resources that participate in a stack's dependency graph. Like other resources, they are explicitly created, may have multiple instances, and may have dependencies on other resources. Providers are referred to using provider references, which are a combination of the provider's URN and its ID. This design addresses the need during a preview to refer to providers that have not yet been physically created and therefore have no ID. All custom resources that are not themselves providers must specify a single provider via a provider reference. The named provider will be used to manage that resource's CRUD operations. If a resource's provider reference changes, the resource must be replaced. Though its URN is not present in the resource's dependency list, the provider should be treated as a dependency of the resource when topologically sorting the dependency graph. Finally, `Invoke` operations must now specify a provider to use for the invocation via a provider reference. ### Engine Changes First-class providers support requires a few changes to the engine: - The engine must have some way to map from provider references to provider plugins. It must be possible to add providers from a stack's checkpoint to this map and to register new/updated providers during the execution of a plan in response to CRUD operations on provider resources. - In order to support updating existing stacks using existing Pulumi programs that may not explicitly instantiate providers, the engine must be able to manage the "default" providers for each package referenced by a checkpoint or Pulumi program. The configuration for a "default" provider is taken from the stack's configuration data. The former need is addressed by adding a provider registry type that is responsible for managing all of the plugins required by a plan. In addition to loading plugins froma checkpoint and providing the ability to map from a provider reference to a provider plugin, this type serves as the provider plugin for providers themselves (i.e. it is the "provider provider"). The latter need is solved via two relatively self-contained changes to plan setup and the eval source. During plan setup, the old checkpoint is scanned for custom resources that do not have a provider reference in order to compute the set of packages that require a default provider. Once this set has been computed, the required default provider definitions are conjured and prepended to the checkpoint's resource list. Each resource that requires a default provider is then updated to refer to the default provider for its package. While an eval source is running, each custom resource registration, resource read, and invoke that does not name a provider is trapped before being returned by the source iterator. If no default provider for the appropriate package has been registered, the eval source synthesizes an appropriate registration, waits for it to complete, and records the registered provider's reference. This reference is injected into the original request, which is then processed as usual. If a default provider was already registered, the recorded reference is used and no new registration occurs. ### SDK Changes These changes only expose first-class providers from the Node.JS SDK. - A new abstract class, `ProviderResource`, can be subclassed and used to instantiate first-class providers. - A new field in `ResourceOptions`, `provider`, can be used to supply a particular provider instance to manage a `CustomResource`'s CRUD operations. - A new type, `InvokeOptions`, can be used to specify options that control the behavior of a call to `pulumi.runtime.invoke`. This type includes a `provider` field that is analogous to `ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
proto.pulumirpc.InvokeRequest.prototype.setProvider = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 3, value);
Implement first-class providers. (#1695) ### First-Class Providers These changes implement support for first-class providers. First-class providers are provider plugins that are exposed as resources via the Pulumi programming model so that they may be explicitly and multiply instantiated. Each instance of a provider resource may be configured differently, and configuration parameters may be source from the outputs of other resources. ### Provider Plugin Changes In order to accommodate the need to verify and diff provider configuration and configure providers without complete configuration information, these changes adjust the high-level provider plugin interface. Two new methods for validating a provider's configuration and diffing changes to the same have been added (`CheckConfig` and `DiffConfig`, respectively), and the type of the configuration bag accepted by `Configure` has been changed to a `PropertyMap`. These changes have not yet been reflected in the provider plugin gRPC interface. We will do this in a set of follow-up changes. Until then, these methods are implemented by adapters: - `CheckConfig` validates that all configuration parameters are string or unknown properties. This is necessary because existing plugins only accept string-typed configuration values. - `DiffConfig` either returns "never replace" if all configuration values are known or "must replace" if any configuration value is unknown. The justification for this behavior is given [here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106) - `Configure` converts the config bag to a legacy config map and configures the provider plugin if all config values are known. If any config value is unknown, the underlying plugin is not configured and the provider may only perform `Check`, `Read`, and `Invoke`, all of which return empty results. We justify this behavior becuase it is only possible during a preview and provides the best experience we can manage with the existing gRPC interface. ### Resource Model Changes Providers are now exposed as resources that participate in a stack's dependency graph. Like other resources, they are explicitly created, may have multiple instances, and may have dependencies on other resources. Providers are referred to using provider references, which are a combination of the provider's URN and its ID. This design addresses the need during a preview to refer to providers that have not yet been physically created and therefore have no ID. All custom resources that are not themselves providers must specify a single provider via a provider reference. The named provider will be used to manage that resource's CRUD operations. If a resource's provider reference changes, the resource must be replaced. Though its URN is not present in the resource's dependency list, the provider should be treated as a dependency of the resource when topologically sorting the dependency graph. Finally, `Invoke` operations must now specify a provider to use for the invocation via a provider reference. ### Engine Changes First-class providers support requires a few changes to the engine: - The engine must have some way to map from provider references to provider plugins. It must be possible to add providers from a stack's checkpoint to this map and to register new/updated providers during the execution of a plan in response to CRUD operations on provider resources. - In order to support updating existing stacks using existing Pulumi programs that may not explicitly instantiate providers, the engine must be able to manage the "default" providers for each package referenced by a checkpoint or Pulumi program. The configuration for a "default" provider is taken from the stack's configuration data. The former need is addressed by adding a provider registry type that is responsible for managing all of the plugins required by a plan. In addition to loading plugins froma checkpoint and providing the ability to map from a provider reference to a provider plugin, this type serves as the provider plugin for providers themselves (i.e. it is the "provider provider"). The latter need is solved via two relatively self-contained changes to plan setup and the eval source. During plan setup, the old checkpoint is scanned for custom resources that do not have a provider reference in order to compute the set of packages that require a default provider. Once this set has been computed, the required default provider definitions are conjured and prepended to the checkpoint's resource list. Each resource that requires a default provider is then updated to refer to the default provider for its package. While an eval source is running, each custom resource registration, resource read, and invoke that does not name a provider is trapped before being returned by the source iterator. If no default provider for the appropriate package has been registered, the eval source synthesizes an appropriate registration, waits for it to complete, and records the registered provider's reference. This reference is injected into the original request, which is then processed as usual. If a default provider was already registered, the recorded reference is used and no new registration occurs. ### SDK Changes These changes only expose first-class providers from the Node.JS SDK. - A new abstract class, `ProviderResource`, can be subclassed and used to instantiate first-class providers. - A new field in `ResourceOptions`, `provider`, can be used to supply a particular provider instance to manage a `CustomResource`'s CRUD operations. - A new type, `InvokeOptions`, can be used to specify options that control the behavior of a call to `pulumi.runtime.invoke`. This type includes a `provider` field that is analogous to `ResourceOptions.provider`.
2018-08-07 02:50:29 +02:00
};
Protobuf changes for provider versioning (#2642) In pursuit of pulumi/pulumi#2389, this commit adds the necessary changes to the resource monitor protocol so that language hosts can communicate exactly what version of a provider should be used when servicing an Invoke, ReadResource, or RegisterResource. The expectation here is that, if a language host provides a version, the engine MUST use EXACTLY that version of a provider plugin in order to service the request.
2019-04-16 19:06:43 +02:00
/**
* optional string version = 4;
* @return {string}
*/
proto.pulumirpc.InvokeRequest.prototype.getVersion = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 4, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.InvokeRequest} returns this
*/
Protobuf changes for provider versioning (#2642) In pursuit of pulumi/pulumi#2389, this commit adds the necessary changes to the resource monitor protocol so that language hosts can communicate exactly what version of a provider should be used when servicing an Invoke, ReadResource, or RegisterResource. The expectation here is that, if a language host provides a version, the engine MUST use EXACTLY that version of a provider plugin in order to service the request.
2019-04-16 19:06:43 +02:00
proto.pulumirpc.InvokeRequest.prototype.setVersion = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 4, value);
Protobuf changes for provider versioning (#2642) In pursuit of pulumi/pulumi#2389, this commit adds the necessary changes to the resource monitor protocol so that language hosts can communicate exactly what version of a provider should be used when servicing an Invoke, ReadResource, or RegisterResource. The expectation here is that, if a language host provides a version, the engine MUST use EXACTLY that version of a provider plugin in order to service the request.
2019-04-16 19:06:43 +02:00
};
Add support for serialized resource references. (#5041) Resources are serialized as their URN, ID, and package version. Each Pulumi package is expected to register itself with the SDK. The package will be invoked to construct appropriate instances of rehydrated resources. Packages are distinguished by their name and their version. This is the foundation of cross-process resources. Related to #2430. Co-authored-by: Mikhail Shilkov <github@mikhail.io> Co-authored-by: Luke Hoban <luke@pulumi.com> Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 18:12:12 +01:00
/**
* optional bool acceptResources = 5;
* @return {boolean}
*/
proto.pulumirpc.InvokeRequest.prototype.getAcceptresources = function() {
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 5, false));
};
/**
* @param {boolean} value
* @return {!proto.pulumirpc.InvokeRequest} returns this
*/
proto.pulumirpc.InvokeRequest.prototype.setAcceptresources = function(value) {
return jspb.Message.setProto3BooleanField(this, 5, value);
};
Add a pre-pass to validate resources before creating/updating This change adds a new Check RPC method on the provider interface, permitting resource providers to perform arbitrary verification on the values of properties. This is useful for validating things that might be difficult to express in the type system, and it runs before *any* modifications are run (so failures can be caight early before it's too late). My favorite motivating example is verifying that an AWS EC2 instance's AMI is available within the target region. This resolves pulumi/coconut#107, although we aren't using this in any resource providers just yet. I'll add a work item now for that...
2017-03-03 03:15:38 +01:00
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.repeatedFields_ = [2];
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.InvokeResponse.toObject(opt_includeInstance, this);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.InvokeResponse} msg The msg instance to transform.
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.toObject = function(includeInstance, msg) {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
var f, obj = {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
pb_return: (f = msg.getReturn()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
failuresList: jspb.Message.toObjectList(msg.getFailuresList(),
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.CheckFailure.toObject, includeInstance)
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.InvokeResponse}
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.deserializeBinary = function(bytes) {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.InvokeResponse;
return proto.pulumirpc.InvokeResponse.deserializeBinaryFromReader(msg, reader);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.InvokeResponse} msg The message object to deserialize into.
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.InvokeResponse}
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.deserializeBinaryFromReader = function(msg, reader) {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.setReturn(value);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
break;
case 2:
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
var value = new proto.pulumirpc.CheckFailure;
reader.readMessage(value,proto.pulumirpc.CheckFailure.deserializeBinaryFromReader);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
msg.addFailures(value);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.prototype.serializeBinary = function() {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.serializeBinaryToWriter(this, writer);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.InvokeResponse} message
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.serializeBinaryToWriter = function(message, writer) {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
var f = undefined;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getReturn();
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
if (f != null) {
writer.writeMessage(
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
1,
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
);
}
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
f = message.getFailuresList();
if (f.length > 0) {
writer.writeRepeatedMessage(
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
2,
f,
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
proto.pulumirpc.CheckFailure.serializeBinaryToWriter
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
);
}
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional google.protobuf.Struct return = 1;
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
* @return {?proto.google.protobuf.Struct}
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.prototype.getReturn = function() {
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 1));
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.InvokeResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.prototype.setReturn = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 1, value);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.InvokeResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.prototype.clearReturn = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setReturn(undefined);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
/**
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.prototype.hasReturn = function() {
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
return jspb.Message.getField(this, 1) != null;
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
/**
* repeated CheckFailure failures = 2;
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!Array<!proto.pulumirpc.CheckFailure>}
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.prototype.getFailuresList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type{!Array<!proto.pulumirpc.CheckFailure>} */ (
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
jspb.Message.getRepeatedWrapperField(this, proto.pulumirpc.CheckFailure, 2));
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!Array<!proto.pulumirpc.CheckFailure>} value
* @return {!proto.pulumirpc.InvokeResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.prototype.setFailuresList = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setRepeatedWrapperField(this, 2, value);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
/**
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
* @param {!proto.pulumirpc.CheckFailure=} opt_value
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
* @param {number=} opt_index
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
* @return {!proto.pulumirpc.CheckFailure}
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.prototype.addFailures = function(opt_value, opt_index) {
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
return jspb.Message.addToRepeatedWrapperField(this, 2, opt_value, proto.pulumirpc.CheckFailure, opt_index);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.InvokeResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.InvokeResponse.prototype.clearFailuresList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setFailuresList([]);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
Initial support for resource methods (authoring from Node.js, calling from Python) (#7363) Adds initial support for resource methods (via a new `Call` gRPC method similar to `Invoke`), with support for authoring methods from Node.js, and calling methods from Python.
2021-06-30 16:48:56 +02:00
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.CallRequest.repeatedFields_ = [9];
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
* Creates an object representation of this proto.
* Field names that are reserved in JavaScript and will be renamed to pb_name.
* Optional fields that are not set will be set to undefined.
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @return {!Object}
*/
proto.pulumirpc.CallRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.CallRequest.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.CallRequest} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.CallRequest.toObject = function(includeInstance, msg) {
var f, obj = {
tok: jspb.Message.getFieldWithDefault(msg, 1, ""),
args: (f = msg.getArgs()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
argdependenciesMap: (f = msg.getArgdependenciesMap()) ? f.toObject(includeInstance, proto.pulumirpc.CallRequest.ArgumentDependencies.toObject) : [],
provider: jspb.Message.getFieldWithDefault(msg, 4, ""),
version: jspb.Message.getFieldWithDefault(msg, 5, ""),
project: jspb.Message.getFieldWithDefault(msg, 6, ""),
stack: jspb.Message.getFieldWithDefault(msg, 7, ""),
configMap: (f = msg.getConfigMap()) ? f.toObject(includeInstance, undefined) : [],
configsecretkeysList: (f = jspb.Message.getRepeatedField(msg, 9)) == null ? undefined : f,
dryrun: jspb.Message.getBooleanFieldWithDefault(msg, 10, false),
parallel: jspb.Message.getFieldWithDefault(msg, 11, 0),
monitorendpoint: jspb.Message.getFieldWithDefault(msg, 12, "")
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.CallRequest}
*/
proto.pulumirpc.CallRequest.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.CallRequest;
return proto.pulumirpc.CallRequest.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.CallRequest} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.CallRequest}
*/
proto.pulumirpc.CallRequest.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.setTok(value);
break;
case 2:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setArgs(value);
break;
case 3:
var value = msg.getArgdependenciesMap();
reader.readMessage(value, function(message, reader) {
jspb.Map.deserializeBinary(message, reader, jspb.BinaryReader.prototype.readString, jspb.BinaryReader.prototype.readMessage, proto.pulumirpc.CallRequest.ArgumentDependencies.deserializeBinaryFromReader, "", new proto.pulumirpc.CallRequest.ArgumentDependencies());
});
break;
case 4:
var value = /** @type {string} */ (reader.readString());
msg.setProvider(value);
break;
case 5:
var value = /** @type {string} */ (reader.readString());
msg.setVersion(value);
break;
case 6:
var value = /** @type {string} */ (reader.readString());
msg.setProject(value);
break;
case 7:
var value = /** @type {string} */ (reader.readString());
msg.setStack(value);
break;
case 8:
var value = msg.getConfigMap();
reader.readMessage(value, function(message, reader) {
jspb.Map.deserializeBinary(message, reader, jspb.BinaryReader.prototype.readString, jspb.BinaryReader.prototype.readString, null, "", "");
});
break;
case 9:
var value = /** @type {string} */ (reader.readString());
msg.addConfigsecretkeys(value);
break;
case 10:
var value = /** @type {boolean} */ (reader.readBool());
msg.setDryrun(value);
break;
case 11:
var value = /** @type {number} */ (reader.readInt32());
msg.setParallel(value);
break;
case 12:
var value = /** @type {string} */ (reader.readString());
msg.setMonitorendpoint(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.CallRequest.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.CallRequest.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.CallRequest} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.CallRequest.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getTok();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
f = message.getArgs();
if (f != null) {
writer.writeMessage(
2,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
f = message.getArgdependenciesMap(true);
if (f && f.getLength() > 0) {
f.serializeBinary(3, writer, jspb.BinaryWriter.prototype.writeString, jspb.BinaryWriter.prototype.writeMessage, proto.pulumirpc.CallRequest.ArgumentDependencies.serializeBinaryToWriter);
}
f = message.getProvider();
if (f.length > 0) {
writer.writeString(
4,
f
);
}
f = message.getVersion();
if (f.length > 0) {
writer.writeString(
5,
f
);
}
f = message.getProject();
if (f.length > 0) {
writer.writeString(
6,
f
);
}
f = message.getStack();
if (f.length > 0) {
writer.writeString(
7,
f
);
}
f = message.getConfigMap(true);
if (f && f.getLength() > 0) {
f.serializeBinary(8, writer, jspb.BinaryWriter.prototype.writeString, jspb.BinaryWriter.prototype.writeString);
}
f = message.getConfigsecretkeysList();
if (f.length > 0) {
writer.writeRepeatedString(
9,
f
);
}
f = message.getDryrun();
if (f) {
writer.writeBool(
10,
f
);
}
f = message.getParallel();
if (f !== 0) {
writer.writeInt32(
11,
f
);
}
f = message.getMonitorendpoint();
if (f.length > 0) {
writer.writeString(
12,
f
);
}
};
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.repeatedFields_ = [1];
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
* Creates an object representation of this proto.
* Field names that are reserved in JavaScript and will be renamed to pb_name.
* Optional fields that are not set will be set to undefined.
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @return {!Object}
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.CallRequest.ArgumentDependencies.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.CallRequest.ArgumentDependencies} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.toObject = function(includeInstance, msg) {
var f, obj = {
urnsList: (f = jspb.Message.getRepeatedField(msg, 1)) == null ? undefined : f
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.CallRequest.ArgumentDependencies}
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.CallRequest.ArgumentDependencies;
return proto.pulumirpc.CallRequest.ArgumentDependencies.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.CallRequest.ArgumentDependencies} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.CallRequest.ArgumentDependencies}
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.addUrns(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.CallRequest.ArgumentDependencies.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.CallRequest.ArgumentDependencies} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getUrnsList();
if (f.length > 0) {
writer.writeRepeatedString(
1,
f
);
}
};
/**
* repeated string urns = 1;
* @return {!Array<string>}
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.prototype.getUrnsList = function() {
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 1));
};
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.CallRequest.ArgumentDependencies} returns this
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.prototype.setUrnsList = function(value) {
return jspb.Message.setField(this, 1, value || []);
};
/**
* @param {string} value
* @param {number=} opt_index
* @return {!proto.pulumirpc.CallRequest.ArgumentDependencies} returns this
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.prototype.addUrns = function(value, opt_index) {
return jspb.Message.addToRepeatedField(this, 1, value, opt_index);
};
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.CallRequest.ArgumentDependencies} returns this
*/
proto.pulumirpc.CallRequest.ArgumentDependencies.prototype.clearUrnsList = function() {
return this.setUrnsList([]);
};
/**
* optional string tok = 1;
* @return {string}
*/
proto.pulumirpc.CallRequest.prototype.getTok = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.setTok = function(value) {
return jspb.Message.setProto3StringField(this, 1, value);
};
/**
* optional google.protobuf.Struct args = 2;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.CallRequest.prototype.getArgs = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 2));
};
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.setArgs = function(value) {
return jspb.Message.setWrapperField(this, 2, value);
};
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.clearArgs = function() {
return this.setArgs(undefined);
};
/**
* Returns whether this field is set.
* @return {boolean}
*/
proto.pulumirpc.CallRequest.prototype.hasArgs = function() {
return jspb.Message.getField(this, 2) != null;
};
/**
* map<string, ArgumentDependencies> argDependencies = 3;
* @param {boolean=} opt_noLazyCreate Do not create the map if
* empty, instead returning `undefined`
* @return {!jspb.Map<string,!proto.pulumirpc.CallRequest.ArgumentDependencies>}
*/
proto.pulumirpc.CallRequest.prototype.getArgdependenciesMap = function(opt_noLazyCreate) {
return /** @type {!jspb.Map<string,!proto.pulumirpc.CallRequest.ArgumentDependencies>} */ (
jspb.Message.getMapField(this, 3, opt_noLazyCreate,
proto.pulumirpc.CallRequest.ArgumentDependencies));
};
/**
* Clears values from the map. The map will be non-null.
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.clearArgdependenciesMap = function() {
this.getArgdependenciesMap().clear();
return this;};
/**
* optional string provider = 4;
* @return {string}
*/
proto.pulumirpc.CallRequest.prototype.getProvider = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 4, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.setProvider = function(value) {
return jspb.Message.setProto3StringField(this, 4, value);
};
/**
* optional string version = 5;
* @return {string}
*/
proto.pulumirpc.CallRequest.prototype.getVersion = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 5, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.setVersion = function(value) {
return jspb.Message.setProto3StringField(this, 5, value);
};
/**
* optional string project = 6;
* @return {string}
*/
proto.pulumirpc.CallRequest.prototype.getProject = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 6, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.setProject = function(value) {
return jspb.Message.setProto3StringField(this, 6, value);
};
/**
* optional string stack = 7;
* @return {string}
*/
proto.pulumirpc.CallRequest.prototype.getStack = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 7, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.setStack = function(value) {
return jspb.Message.setProto3StringField(this, 7, value);
};
/**
* map<string, string> config = 8;
* @param {boolean=} opt_noLazyCreate Do not create the map if
* empty, instead returning `undefined`
* @return {!jspb.Map<string,string>}
*/
proto.pulumirpc.CallRequest.prototype.getConfigMap = function(opt_noLazyCreate) {
return /** @type {!jspb.Map<string,string>} */ (
jspb.Message.getMapField(this, 8, opt_noLazyCreate,
null));
};
/**
* Clears values from the map. The map will be non-null.
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.clearConfigMap = function() {
this.getConfigMap().clear();
return this;};
/**
* repeated string configSecretKeys = 9;
* @return {!Array<string>}
*/
proto.pulumirpc.CallRequest.prototype.getConfigsecretkeysList = function() {
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 9));
};
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.setConfigsecretkeysList = function(value) {
return jspb.Message.setField(this, 9, value || []);
};
/**
* @param {string} value
* @param {number=} opt_index
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.addConfigsecretkeys = function(value, opt_index) {
return jspb.Message.addToRepeatedField(this, 9, value, opt_index);
};
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.clearConfigsecretkeysList = function() {
return this.setConfigsecretkeysList([]);
};
/**
* optional bool dryRun = 10;
* @return {boolean}
*/
proto.pulumirpc.CallRequest.prototype.getDryrun = function() {
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 10, false));
};
/**
* @param {boolean} value
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.setDryrun = function(value) {
return jspb.Message.setProto3BooleanField(this, 10, value);
};
/**
* optional int32 parallel = 11;
* @return {number}
*/
proto.pulumirpc.CallRequest.prototype.getParallel = function() {
return /** @type {number} */ (jspb.Message.getFieldWithDefault(this, 11, 0));
};
/**
* @param {number} value
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.setParallel = function(value) {
return jspb.Message.setProto3IntField(this, 11, value);
};
/**
* optional string monitorEndpoint = 12;
* @return {string}
*/
proto.pulumirpc.CallRequest.prototype.getMonitorendpoint = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 12, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.CallRequest} returns this
*/
proto.pulumirpc.CallRequest.prototype.setMonitorendpoint = function(value) {
return jspb.Message.setProto3StringField(this, 12, value);
};
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.CallResponse.repeatedFields_ = [3];
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
* Creates an object representation of this proto.
* Field names that are reserved in JavaScript and will be renamed to pb_name.
* Optional fields that are not set will be set to undefined.
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @return {!Object}
*/
proto.pulumirpc.CallResponse.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.CallResponse.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.CallResponse} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.CallResponse.toObject = function(includeInstance, msg) {
var f, obj = {
pb_return: (f = msg.getReturn()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
returndependenciesMap: (f = msg.getReturndependenciesMap()) ? f.toObject(includeInstance, proto.pulumirpc.CallResponse.ReturnDependencies.toObject) : [],
failuresList: jspb.Message.toObjectList(msg.getFailuresList(),
proto.pulumirpc.CheckFailure.toObject, includeInstance)
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.CallResponse}
*/
proto.pulumirpc.CallResponse.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.CallResponse;
return proto.pulumirpc.CallResponse.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.CallResponse} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.CallResponse}
*/
proto.pulumirpc.CallResponse.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setReturn(value);
break;
case 2:
var value = msg.getReturndependenciesMap();
reader.readMessage(value, function(message, reader) {
jspb.Map.deserializeBinary(message, reader, jspb.BinaryReader.prototype.readString, jspb.BinaryReader.prototype.readMessage, proto.pulumirpc.CallResponse.ReturnDependencies.deserializeBinaryFromReader, "", new proto.pulumirpc.CallResponse.ReturnDependencies());
});
break;
case 3:
var value = new proto.pulumirpc.CheckFailure;
reader.readMessage(value,proto.pulumirpc.CheckFailure.deserializeBinaryFromReader);
msg.addFailures(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.CallResponse.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.CallResponse.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.CallResponse} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.CallResponse.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getReturn();
if (f != null) {
writer.writeMessage(
1,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
f = message.getReturndependenciesMap(true);
if (f && f.getLength() > 0) {
f.serializeBinary(2, writer, jspb.BinaryWriter.prototype.writeString, jspb.BinaryWriter.prototype.writeMessage, proto.pulumirpc.CallResponse.ReturnDependencies.serializeBinaryToWriter);
}
f = message.getFailuresList();
if (f.length > 0) {
writer.writeRepeatedMessage(
3,
f,
proto.pulumirpc.CheckFailure.serializeBinaryToWriter
);
}
};
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.CallResponse.ReturnDependencies.repeatedFields_ = [1];
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
* Creates an object representation of this proto.
* Field names that are reserved in JavaScript and will be renamed to pb_name.
* Optional fields that are not set will be set to undefined.
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @return {!Object}
*/
proto.pulumirpc.CallResponse.ReturnDependencies.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.CallResponse.ReturnDependencies.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.CallResponse.ReturnDependencies} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.CallResponse.ReturnDependencies.toObject = function(includeInstance, msg) {
var f, obj = {
urnsList: (f = jspb.Message.getRepeatedField(msg, 1)) == null ? undefined : f
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.CallResponse.ReturnDependencies}
*/
proto.pulumirpc.CallResponse.ReturnDependencies.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.CallResponse.ReturnDependencies;
return proto.pulumirpc.CallResponse.ReturnDependencies.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.CallResponse.ReturnDependencies} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.CallResponse.ReturnDependencies}
*/
proto.pulumirpc.CallResponse.ReturnDependencies.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.addUrns(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.CallResponse.ReturnDependencies.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.CallResponse.ReturnDependencies.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.CallResponse.ReturnDependencies} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.CallResponse.ReturnDependencies.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getUrnsList();
if (f.length > 0) {
writer.writeRepeatedString(
1,
f
);
}
};
/**
* repeated string urns = 1;
* @return {!Array<string>}
*/
proto.pulumirpc.CallResponse.ReturnDependencies.prototype.getUrnsList = function() {
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 1));
};
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.CallResponse.ReturnDependencies} returns this
*/
proto.pulumirpc.CallResponse.ReturnDependencies.prototype.setUrnsList = function(value) {
return jspb.Message.setField(this, 1, value || []);
};
/**
* @param {string} value
* @param {number=} opt_index
* @return {!proto.pulumirpc.CallResponse.ReturnDependencies} returns this
*/
proto.pulumirpc.CallResponse.ReturnDependencies.prototype.addUrns = function(value, opt_index) {
return jspb.Message.addToRepeatedField(this, 1, value, opt_index);
};
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.CallResponse.ReturnDependencies} returns this
*/
proto.pulumirpc.CallResponse.ReturnDependencies.prototype.clearUrnsList = function() {
return this.setUrnsList([]);
};
/**
* optional google.protobuf.Struct return = 1;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.CallResponse.prototype.getReturn = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 1));
};
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.CallResponse} returns this
*/
proto.pulumirpc.CallResponse.prototype.setReturn = function(value) {
return jspb.Message.setWrapperField(this, 1, value);
};
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.CallResponse} returns this
*/
proto.pulumirpc.CallResponse.prototype.clearReturn = function() {
return this.setReturn(undefined);
};
/**
* Returns whether this field is set.
* @return {boolean}
*/
proto.pulumirpc.CallResponse.prototype.hasReturn = function() {
return jspb.Message.getField(this, 1) != null;
};
/**
* map<string, ReturnDependencies> returnDependencies = 2;
* @param {boolean=} opt_noLazyCreate Do not create the map if
* empty, instead returning `undefined`
* @return {!jspb.Map<string,!proto.pulumirpc.CallResponse.ReturnDependencies>}
*/
proto.pulumirpc.CallResponse.prototype.getReturndependenciesMap = function(opt_noLazyCreate) {
return /** @type {!jspb.Map<string,!proto.pulumirpc.CallResponse.ReturnDependencies>} */ (
jspb.Message.getMapField(this, 2, opt_noLazyCreate,
proto.pulumirpc.CallResponse.ReturnDependencies));
};
/**
* Clears values from the map. The map will be non-null.
* @return {!proto.pulumirpc.CallResponse} returns this
*/
proto.pulumirpc.CallResponse.prototype.clearReturndependenciesMap = function() {
this.getReturndependenciesMap().clear();
return this;};
/**
* repeated CheckFailure failures = 3;
* @return {!Array<!proto.pulumirpc.CheckFailure>}
*/
proto.pulumirpc.CallResponse.prototype.getFailuresList = function() {
return /** @type{!Array<!proto.pulumirpc.CheckFailure>} */ (
jspb.Message.getRepeatedWrapperField(this, proto.pulumirpc.CheckFailure, 3));
};
/**
* @param {!Array<!proto.pulumirpc.CheckFailure>} value
* @return {!proto.pulumirpc.CallResponse} returns this
*/
proto.pulumirpc.CallResponse.prototype.setFailuresList = function(value) {
return jspb.Message.setRepeatedWrapperField(this, 3, value);
};
/**
* @param {!proto.pulumirpc.CheckFailure=} opt_value
* @param {number=} opt_index
* @return {!proto.pulumirpc.CheckFailure}
*/
proto.pulumirpc.CallResponse.prototype.addFailures = function(opt_value, opt_index) {
return jspb.Message.addToRepeatedWrapperField(this, 3, opt_value, proto.pulumirpc.CheckFailure, opt_index);
};
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.CallResponse} returns this
*/
proto.pulumirpc.CallResponse.prototype.clearFailuresList = function() {
return this.setFailuresList([]);
};
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.CheckRequest.toObject(opt_includeInstance, this);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CheckRequest} msg The msg instance to transform.
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckRequest.toObject = function(includeInstance, msg) {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
var f, obj = {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
urn: jspb.Message.getFieldWithDefault(msg, 1, ""),
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
olds: (f = msg.getOlds()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
news: (f = msg.getNews()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f)
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.CheckRequest}
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckRequest.deserializeBinary = function(bytes) {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.CheckRequest;
return proto.pulumirpc.CheckRequest.deserializeBinaryFromReader(msg, reader);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CheckRequest} msg The message object to deserialize into.
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.CheckRequest}
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckRequest.deserializeBinaryFromReader = function(msg, reader) {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.setUrn(value);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
break;
case 2:
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
msg.setOlds(value);
break;
case 3:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setNews(value);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckRequest.prototype.serializeBinary = function() {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckRequest.serializeBinaryToWriter(this, writer);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CheckRequest} message
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckRequest.serializeBinaryToWriter = function(message, writer) {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
var f = undefined;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getUrn();
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
if (f.length > 0) {
writer.writeString(
1,
f
);
}
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
f = message.getOlds();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
if (f != null) {
writer.writeMessage(
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
2,
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
);
}
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
f = message.getNews();
if (f != null) {
writer.writeMessage(
3,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional string urn = 1;
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
* @return {string}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckRequest.prototype.getUrn = function() {
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.CheckRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckRequest.prototype.setUrn = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
};
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
/**
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
* optional google.protobuf.Struct olds = 2;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {?proto.google.protobuf.Struct}
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
*/
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
proto.pulumirpc.CheckRequest.prototype.getOlds = function() {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 2));
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.CheckRequest} returns this
*/
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
proto.pulumirpc.CheckRequest.prototype.setOlds = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 2, value);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.CheckRequest} returns this
*/
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
proto.pulumirpc.CheckRequest.prototype.clearOlds = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setOlds(undefined);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
*/
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
proto.pulumirpc.CheckRequest.prototype.hasOlds = function() {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
return jspb.Message.getField(this, 2) != null;
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
/**
* optional google.protobuf.Struct news = 3;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.CheckRequest.prototype.getNews = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 3));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.CheckRequest} returns this
*/
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
proto.pulumirpc.CheckRequest.prototype.setNews = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 3, value);
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.CheckRequest} returns this
*/
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
proto.pulumirpc.CheckRequest.prototype.clearNews = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setNews(undefined);
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
*/
proto.pulumirpc.CheckRequest.prototype.hasNews = function() {
return jspb.Message.getField(this, 3) != null;
};
Redo object monikers This change overhauls the way we do object monikers. The old mechanism, generating monikers using graph paths, was far too brittle and prone to collisions. The new approach mixes some amount of "automatic scoping" plus some "explicit naming." Although there is some explicitness, this is arguably a good thing, as the monikers will be relatable back to the source more readily by developers inspecting the graph and resource state. Each moniker has four parts: <Namespace>::<AllocModule>::<Type>::<Name> wherein each element is the following: <Namespace> The namespace being deployed into <AllocModule> The module in which the object was allocated <Type> The type of the resource <Name> The assigned name of the resource The <Namespace> is essentially the deployment target -- so "prod", "stage", etc -- although it is more general purpose to allow for future namespacing within a target (e.g., "prod/customer1", etc); for now this is rudimentary, however, see marapongo/mu#94. The <AllocModule> is the token for the code that contained the 'new' that led to this object being created. In the future, we may wish to extend this to also track the module under evaluation. (This is a nice aspect of monikers; they can become arbitrarily complex, so long as they are precise, and not prone to false positives/negatives.) The <Name> warrants more discussion. The resource provider is consulted via a new gRPC method, Name, that fetches the name. How the provider does this is entirely up to it. For some resource types, the resource may have properties that developers must set (e.g., `new Bucket("foo")`); for other providers, perhaps the resource intrinsically has a property that explicitly and uniquely qualifies the object (e.g., AWS SecurityGroups, via `new SecurityGroup({groupName: "my-sg"}`); and finally, it's conceivable that a provider might auto-generate the name (e.g., such as an AWS Lambda whose name could simply be a hash of the source code contents). This should overall produce better results with respect to moniker collisions, ability to match resources, and the usability of the system.
2017-02-24 23:50:02 +01:00
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.CheckResponse.repeatedFields_ = [2];
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckResponse.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.CheckResponse.toObject(opt_includeInstance, this);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CheckResponse} msg The msg instance to transform.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckResponse.toObject = function(includeInstance, msg) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var f, obj = {
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
inputs: (f = msg.getInputs()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
failuresList: jspb.Message.toObjectList(msg.getFailuresList(),
proto.pulumirpc.CheckFailure.toObject, includeInstance)
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.CheckResponse}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckResponse.deserializeBinary = function(bytes) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.CheckResponse;
return proto.pulumirpc.CheckResponse.deserializeBinaryFromReader(msg, reader);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CheckResponse} msg The message object to deserialize into.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.CheckResponse}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckResponse.deserializeBinaryFromReader = function(msg, reader) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
msg.setInputs(value);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
break;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
case 2:
var value = new proto.pulumirpc.CheckFailure;
reader.readMessage(value,proto.pulumirpc.CheckFailure.deserializeBinaryFromReader);
msg.addFailures(value);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckResponse.prototype.serializeBinary = function() {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckResponse.serializeBinaryToWriter(this, writer);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CheckResponse} message
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckResponse.serializeBinaryToWriter = function(message, writer) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var f = undefined;
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
f = message.getInputs();
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
if (f != null) {
writer.writeMessage(
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
1,
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getFailuresList();
if (f.length > 0) {
writer.writeRepeatedMessage(
2,
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
f,
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.serializeBinaryToWriter
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
);
}
};
/**
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
* optional google.protobuf.Struct inputs = 1;
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {?proto.google.protobuf.Struct}
*/
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
proto.pulumirpc.CheckResponse.prototype.getInputs = function() {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
return /** @type{?proto.google.protobuf.Struct} */ (
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 1));
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.CheckResponse} returns this
*/
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
proto.pulumirpc.CheckResponse.prototype.setInputs = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 1, value);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.CheckResponse} returns this
*/
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
proto.pulumirpc.CheckResponse.prototype.clearInputs = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setInputs(undefined);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Return all computed inputs from Provider.Check. As documented in issue #616, the inputs/defaults/outputs model we have today has fundamental problems. The crux of the issue is that our current design requires that defaults present in the old state of a resource are applied to the new inputs for that resource. Unfortunately, it is not possible for the engine to decide which defaults remain applicable and which do not; only the provider has that knowledge. These changes take a more tactical approach to resolving this issue than that originally proposed in #616 that avoids breaking compatibility with existing checkpoints. Rather than treating the Pulumi inputs as the provider input properties for a resource, these inputs are first translated by `Check`. In order to accommodate provider defaults that were chosen for the old resource but should not change for the new, `Check` now takes the old provider inputs as well as the new Pulumi inputs. Rather than the Pulumi inputs and provider defaults, the provider inputs returned by `Check` are recorded in the checkpoint file. Put simply, these changes remove defaults as a first-class concept (except inasmuch as is required to retain the ability to read old checkpoint files) and move the responsibilty for manging and merging defaults into the provider that supplies them. Fixes #616.
2017-12-03 01:34:16 +01:00
proto.pulumirpc.CheckResponse.prototype.hasInputs = function() {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
return jspb.Message.getField(this, 1) != null;
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* repeated CheckFailure failures = 2;
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!Array<!proto.pulumirpc.CheckFailure>}
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckResponse.prototype.getFailuresList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type{!Array<!proto.pulumirpc.CheckFailure>} */ (
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
jspb.Message.getRepeatedWrapperField(this, proto.pulumirpc.CheckFailure, 2));
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!Array<!proto.pulumirpc.CheckFailure>} value
* @return {!proto.pulumirpc.CheckResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckResponse.prototype.setFailuresList = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setRepeatedWrapperField(this, 2, value);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
/**
* @param {!proto.pulumirpc.CheckFailure=} opt_value
* @param {number=} opt_index
* @return {!proto.pulumirpc.CheckFailure}
*/
proto.pulumirpc.CheckResponse.prototype.addFailures = function(opt_value, opt_index) {
return jspb.Message.addToRepeatedWrapperField(this, 2, opt_value, proto.pulumirpc.CheckFailure, opt_index);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.CheckResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckResponse.prototype.clearFailuresList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setFailuresList([]);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.CheckFailure.toObject(opt_includeInstance, this);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CheckFailure} msg The msg instance to transform.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.toObject = function(includeInstance, msg) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var f, obj = {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
property: jspb.Message.getFieldWithDefault(msg, 1, ""),
reason: jspb.Message.getFieldWithDefault(msg, 2, "")
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.CheckFailure}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.deserializeBinary = function(bytes) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.CheckFailure;
return proto.pulumirpc.CheckFailure.deserializeBinaryFromReader(msg, reader);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CheckFailure} msg The message object to deserialize into.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.CheckFailure}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.deserializeBinaryFromReader = function(msg, reader) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.setProperty(value);
break;
case 2:
var value = /** @type {string} */ (reader.readString());
msg.setReason(value);
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
break;
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.prototype.serializeBinary = function() {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.serializeBinaryToWriter(this, writer);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CheckFailure} message
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.serializeBinaryToWriter = function(message, writer) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var f = undefined;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getProperty();
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
if (f.length > 0) {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
writer.writeString(
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
1,
f
);
}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getReason();
if (f.length > 0) {
writer.writeString(
2,
f
);
}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional string property = 1;
* @return {string}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.prototype.getProperty = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.CheckFailure} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.prototype.setProperty = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional string reason = 2;
* @return {string}
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.prototype.getReason = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 2, ""));
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.CheckFailure} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CheckFailure.prototype.setReason = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 2, value);
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
};
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.DiffRequest.repeatedFields_ = [5];
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.DiffRequest.toObject(opt_includeInstance, this);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.DiffRequest} msg The msg instance to transform.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.toObject = function(includeInstance, msg) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var f, obj = {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
id: jspb.Message.getFieldWithDefault(msg, 1, ""),
urn: jspb.Message.getFieldWithDefault(msg, 2, ""),
olds: (f = msg.getOlds()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
news: (f = msg.getNews()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
ignorechangesList: (f = jspb.Message.getRepeatedField(msg, 5)) == null ? undefined : f
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.DiffRequest}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.deserializeBinary = function(bytes) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.DiffRequest;
return proto.pulumirpc.DiffRequest.deserializeBinaryFromReader(msg, reader);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.DiffRequest} msg The message object to deserialize into.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.DiffRequest}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.deserializeBinaryFromReader = function(msg, reader) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.setId(value);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
break;
case 2:
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var value = /** @type {string} */ (reader.readString());
msg.setUrn(value);
break;
case 3:
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.setOlds(value);
break;
case 4:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setNews(value);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
break;
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
case 5:
var value = /** @type {string} */ (reader.readString());
msg.addIgnorechanges(value);
break;
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.serializeBinary = function() {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.serializeBinaryToWriter(this, writer);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
return writer.getResultBuffer();
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.DiffRequest} message
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
*/
proto.pulumirpc.DiffRequest.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getId();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
f = message.getUrn();
if (f.length > 0) {
writer.writeString(
2,
f
);
}
f = message.getOlds();
if (f != null) {
writer.writeMessage(
3,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
f = message.getNews();
if (f != null) {
writer.writeMessage(
4,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
f = message.getIgnorechangesList();
if (f.length > 0) {
writer.writeRepeatedString(
5,
f
);
}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
};
/**
* optional string id = 1;
* @return {string}
*/
proto.pulumirpc.DiffRequest.prototype.getId = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.DiffRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.setId = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
};
/**
* optional string urn = 2;
* @return {string}
*/
proto.pulumirpc.DiffRequest.prototype.getUrn = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 2, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.DiffRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.setUrn = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 2, value);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
};
/**
* optional google.protobuf.Struct olds = 3;
* @return {?proto.google.protobuf.Struct}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.getOlds = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 3));
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.DiffRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.setOlds = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 3, value);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.DiffRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.clearOlds = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setOlds(undefined);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
*/
proto.pulumirpc.DiffRequest.prototype.hasOlds = function() {
return jspb.Message.getField(this, 3) != null;
};
/**
* optional google.protobuf.Struct news = 4;
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
* @return {?proto.google.protobuf.Struct}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.getNews = function() {
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
return /** @type{?proto.google.protobuf.Struct} */ (
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 4));
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.DiffRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.setNews = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 4, value);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.DiffRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.clearNews = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setNews(undefined);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffRequest.prototype.hasNews = function() {
return jspb.Message.getField(this, 4) != null;
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
/**
* repeated string ignoreChanges = 5;
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!Array<string>}
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
*/
proto.pulumirpc.DiffRequest.prototype.getIgnorechangesList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 5));
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.DiffRequest} returns this
*/
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
proto.pulumirpc.DiffRequest.prototype.setIgnorechangesList = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setField(this, 5, value || []);
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
};
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {string} value
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
* @param {number=} opt_index
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!proto.pulumirpc.DiffRequest} returns this
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
*/
proto.pulumirpc.DiffRequest.prototype.addIgnorechanges = function(value, opt_index) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.addToRepeatedField(this, 5, value, opt_index);
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.DiffRequest} returns this
*/
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
proto.pulumirpc.DiffRequest.prototype.clearIgnorechangesList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setIgnorechangesList([]);
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
};
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
* @return {!Object}
*/
proto.pulumirpc.PropertyDiff.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.PropertyDiff.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.PropertyDiff} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.PropertyDiff.toObject = function(includeInstance, msg) {
var f, obj = {
kind: jspb.Message.getFieldWithDefault(msg, 1, 0),
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
inputdiff: jspb.Message.getBooleanFieldWithDefault(msg, 2, false)
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.PropertyDiff}
*/
proto.pulumirpc.PropertyDiff.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.PropertyDiff;
return proto.pulumirpc.PropertyDiff.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.PropertyDiff} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.PropertyDiff}
*/
proto.pulumirpc.PropertyDiff.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {!proto.pulumirpc.PropertyDiff.Kind} */ (reader.readEnum());
msg.setKind(value);
break;
case 2:
var value = /** @type {boolean} */ (reader.readBool());
msg.setInputdiff(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.PropertyDiff.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.PropertyDiff.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.PropertyDiff} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.PropertyDiff.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getKind();
if (f !== 0.0) {
writer.writeEnum(
1,
f
);
}
f = message.getInputdiff();
if (f) {
writer.writeBool(
2,
f
);
}
};
/**
* @enum {number}
*/
proto.pulumirpc.PropertyDiff.Kind = {
ADD: 0,
ADD_REPLACE: 1,
DELETE: 2,
DELETE_REPLACE: 3,
UPDATE: 4,
UPDATE_REPLACE: 5
};
/**
* optional Kind kind = 1;
* @return {!proto.pulumirpc.PropertyDiff.Kind}
*/
proto.pulumirpc.PropertyDiff.prototype.getKind = function() {
return /** @type {!proto.pulumirpc.PropertyDiff.Kind} */ (jspb.Message.getFieldWithDefault(this, 1, 0));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!proto.pulumirpc.PropertyDiff.Kind} value
* @return {!proto.pulumirpc.PropertyDiff} returns this
*/
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
proto.pulumirpc.PropertyDiff.prototype.setKind = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3EnumField(this, 1, value);
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
};
/**
* optional bool inputDiff = 2;
* @return {boolean}
*/
proto.pulumirpc.PropertyDiff.prototype.getInputdiff = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 2, false));
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
};
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean} value
* @return {!proto.pulumirpc.PropertyDiff} returns this
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
proto.pulumirpc.PropertyDiff.prototype.setInputdiff = function(value) {
return jspb.Message.setProto3BooleanField(this, 2, value);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
proto.pulumirpc.DiffResponse.repeatedFields_ = [1,2,5];
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.DiffResponse.toObject(opt_includeInstance, this);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.DiffResponse} msg The msg instance to transform.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.toObject = function(includeInstance, msg) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var f, obj = {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
replacesList: (f = jspb.Message.getRepeatedField(msg, 1)) == null ? undefined : f,
stablesList: (f = jspb.Message.getRepeatedField(msg, 2)) == null ? undefined : f,
deletebeforereplace: jspb.Message.getBooleanFieldWithDefault(msg, 3, false),
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
changes: jspb.Message.getFieldWithDefault(msg, 4, 0),
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
diffsList: (f = jspb.Message.getRepeatedField(msg, 5)) == null ? undefined : f,
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
detaileddiffMap: (f = msg.getDetaileddiffMap()) ? f.toObject(includeInstance, proto.pulumirpc.PropertyDiff.toObject) : [],
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
hasdetaileddiff: jspb.Message.getBooleanFieldWithDefault(msg, 7, false)
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.DiffResponse}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.deserializeBinary = function(bytes) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.DiffResponse;
return proto.pulumirpc.DiffResponse.deserializeBinaryFromReader(msg, reader);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.DiffResponse} msg The message object to deserialize into.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.DiffResponse}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.deserializeBinaryFromReader = function(msg, reader) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
var value = /** @type {string} */ (reader.readString());
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.addReplaces(value);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
break;
case 2:
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var value = /** @type {string} */ (reader.readString());
msg.addStables(value);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
break;
Add rudimentary delete-before-create support This change adds rudimentary delete-before-create support (see pulumi/pulumi#450). This cannot possibly be complete until we also implement pulumi/pulumi#624, becuase we may try to delete a resource while it still has dependent resources (which almost certainly will fail). But until then, we can use this to manually unwedge ourselves for leaf-node resources that do not support old and new resources living side-by-side.
2017-12-10 17:37:22 +01:00
case 3:
var value = /** @type {boolean} */ (reader.readBool());
msg.setDeletebeforereplace(value);
break;
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
case 4:
var value = /** @type {!proto.pulumirpc.DiffResponse.DiffChanges} */ (reader.readEnum());
msg.setChanges(value);
break;
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
case 5:
var value = /** @type {string} */ (reader.readString());
msg.addDiffs(value);
break;
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
case 6:
var value = msg.getDetaileddiffMap();
reader.readMessage(value, function(message, reader) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
jspb.Map.deserializeBinary(message, reader, jspb.BinaryReader.prototype.readString, jspb.BinaryReader.prototype.readMessage, proto.pulumirpc.PropertyDiff.deserializeBinaryFromReader, "", new proto.pulumirpc.PropertyDiff());
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
});
break;
case 7:
var value = /** @type {boolean} */ (reader.readBool());
msg.setHasdetaileddiff(value);
break;
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.prototype.serializeBinary = function() {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.serializeBinaryToWriter(this, writer);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.DiffResponse} message
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.serializeBinaryToWriter = function(message, writer) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var f = undefined;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getReplacesList();
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
if (f.length > 0) {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
writer.writeRepeatedString(
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
1,
f
);
}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getStablesList();
if (f.length > 0) {
writer.writeRepeatedString(
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
2,
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
);
}
Add rudimentary delete-before-create support This change adds rudimentary delete-before-create support (see pulumi/pulumi#450). This cannot possibly be complete until we also implement pulumi/pulumi#624, becuase we may try to delete a resource while it still has dependent resources (which almost certainly will fail). But until then, we can use this to manually unwedge ourselves for leaf-node resources that do not support old and new resources living side-by-side.
2017-12-10 17:37:22 +01:00
f = message.getDeletebeforereplace();
if (f) {
writer.writeBool(
3,
f
);
}
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
f = message.getChanges();
if (f !== 0.0) {
writer.writeEnum(
4,
f
);
}
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
f = message.getDiffsList();
if (f.length > 0) {
writer.writeRepeatedString(
5,
f
);
}
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
f = message.getDetaileddiffMap(true);
if (f && f.getLength() > 0) {
f.serializeBinary(6, writer, jspb.BinaryWriter.prototype.writeString, jspb.BinaryWriter.prototype.writeMessage, proto.pulumirpc.PropertyDiff.serializeBinaryToWriter);
}
f = message.getHasdetaileddiff();
if (f) {
writer.writeBool(
7,
f
);
}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
/**
* @enum {number}
*/
proto.pulumirpc.DiffResponse.DiffChanges = {
DIFF_UNKNOWN: 0,
DIFF_NONE: 1,
DIFF_SOME: 2
};
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* repeated string replaces = 1;
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!Array<string>}
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.prototype.getReplacesList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 1));
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.DiffResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.prototype.setReplacesList = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setField(this, 1, value || []);
Explicitly track default properties This changes the RPC interfaces between Lumi and provider ever so slightly, so that we can track default properties explicitly. This is required to perform accurate diffing between inputs provided by the developer, inputs provided by the system, and outputs. This is particularly important for default values that may be indeterminite, such as those we use in the bridge to auto-generate unique IDs. Otherwise, we fail to reapply defaults correctly, and trick the provider into thinking that properties changed when they did not. This is a small step towards pulumi/lumi#306, in which we will defer even more responsibility for diffing semantics to the providers.
2017-08-01 03:26:15 +02:00
};
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {string} value
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {number=} opt_index
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!proto.pulumirpc.DiffResponse} returns this
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.prototype.addReplaces = function(value, opt_index) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.addToRepeatedField(this, 1, value, opt_index);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.DiffResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.prototype.clearReplacesList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setReplacesList([]);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
/**
* repeated string stables = 2;
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!Array<string>}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
*/
proto.pulumirpc.DiffResponse.prototype.getStablesList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 2));
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.DiffResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.prototype.setStablesList = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setField(this, 2, value || []);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {string} value
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {number=} opt_index
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!proto.pulumirpc.DiffResponse} returns this
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.prototype.addStables = function(value, opt_index) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.addToRepeatedField(this, 2, value, opt_index);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.DiffResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DiffResponse.prototype.clearStablesList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setStablesList([]);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Add rudimentary delete-before-create support This change adds rudimentary delete-before-create support (see pulumi/pulumi#450). This cannot possibly be complete until we also implement pulumi/pulumi#624, becuase we may try to delete a resource while it still has dependent resources (which almost certainly will fail). But until then, we can use this to manually unwedge ourselves for leaf-node resources that do not support old and new resources living side-by-side.
2017-12-10 17:37:22 +01:00
/**
* optional bool deleteBeforeReplace = 3;
* @return {boolean}
*/
proto.pulumirpc.DiffResponse.prototype.getDeletebeforereplace = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 3, false));
Add rudimentary delete-before-create support This change adds rudimentary delete-before-create support (see pulumi/pulumi#450). This cannot possibly be complete until we also implement pulumi/pulumi#624, becuase we may try to delete a resource while it still has dependent resources (which almost certainly will fail). But until then, we can use this to manually unwedge ourselves for leaf-node resources that do not support old and new resources living side-by-side.
2017-12-10 17:37:22 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {boolean} value
* @return {!proto.pulumirpc.DiffResponse} returns this
*/
Add rudimentary delete-before-create support This change adds rudimentary delete-before-create support (see pulumi/pulumi#450). This cannot possibly be complete until we also implement pulumi/pulumi#624, becuase we may try to delete a resource while it still has dependent resources (which almost certainly will fail). But until then, we can use this to manually unwedge ourselves for leaf-node resources that do not support old and new resources living side-by-side.
2017-12-10 17:37:22 +01:00
proto.pulumirpc.DiffResponse.prototype.setDeletebeforereplace = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3BooleanField(this, 3, value);
Add rudimentary delete-before-create support This change adds rudimentary delete-before-create support (see pulumi/pulumi#450). This cannot possibly be complete until we also implement pulumi/pulumi#624, becuase we may try to delete a resource while it still has dependent resources (which almost certainly will fail). But until then, we can use this to manually unwedge ourselves for leaf-node resources that do not support old and new resources living side-by-side.
2017-12-10 17:37:22 +01:00
};
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
/**
* optional DiffChanges changes = 4;
* @return {!proto.pulumirpc.DiffResponse.DiffChanges}
*/
proto.pulumirpc.DiffResponse.prototype.getChanges = function() {
return /** @type {!proto.pulumirpc.DiffResponse.DiffChanges} */ (jspb.Message.getFieldWithDefault(this, 4, 0));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!proto.pulumirpc.DiffResponse.DiffChanges} value
* @return {!proto.pulumirpc.DiffResponse} returns this
*/
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
proto.pulumirpc.DiffResponse.prototype.setChanges = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3EnumField(this, 4, value);
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
/**
* repeated string diffs = 5;
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!Array<string>}
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
*/
proto.pulumirpc.DiffResponse.prototype.getDiffsList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 5));
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.DiffResponse} returns this
*/
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
proto.pulumirpc.DiffResponse.prototype.setDiffsList = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setField(this, 5, value || []);
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
};
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {string} value
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
* @param {number=} opt_index
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!proto.pulumirpc.DiffResponse} returns this
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
*/
proto.pulumirpc.DiffResponse.prototype.addDiffs = function(value, opt_index) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.addToRepeatedField(this, 5, value, opt_index);
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.DiffResponse} returns this
*/
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
proto.pulumirpc.DiffResponse.prototype.clearDiffsList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setDiffsList([]);
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
};
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
/**
* map<string, PropertyDiff> detailedDiff = 6;
* @param {boolean=} opt_noLazyCreate Do not create the map if
* empty, instead returning `undefined`
* @return {!jspb.Map<string,!proto.pulumirpc.PropertyDiff>}
*/
proto.pulumirpc.DiffResponse.prototype.getDetaileddiffMap = function(opt_noLazyCreate) {
return /** @type {!jspb.Map<string,!proto.pulumirpc.PropertyDiff>} */ (
jspb.Message.getMapField(this, 6, opt_noLazyCreate,
proto.pulumirpc.PropertyDiff));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears values from the map. The map will be non-null.
* @return {!proto.pulumirpc.DiffResponse} returns this
*/
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
proto.pulumirpc.DiffResponse.prototype.clearDetaileddiffMap = function() {
this.getDetaileddiffMap().clear();
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this;};
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
/**
* optional bool hasDetailedDiff = 7;
* @return {boolean}
*/
proto.pulumirpc.DiffResponse.prototype.getHasdetaileddiff = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 7, false));
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {boolean} value
* @return {!proto.pulumirpc.DiffResponse} returns this
*/
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
proto.pulumirpc.DiffResponse.prototype.setHasdetaileddiff = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3BooleanField(this, 7, value);
Defer all diffs to resource providers. (#2849) Thse changes make a subtle but critical adjustment to the process the Pulumi engine uses to determine whether or not a difference exists between a resource's actual and desired states, and adjusts the way this difference is calculated and displayed accordingly. Today, the Pulumi engine get the first chance to decide whether or not there is a difference between a resource's actual and desired states. It does this by comparing the current set of inputs for a resource (i.e. the inputs from the running Pulumi program) with the last set of inputs used to update the resource. If there is no difference between the old and new inputs, the engine decides that no change is necessary without consulting the resource's provider. Only if there are changes does the engine consult the resource's provider for more information about the difference. This can be problematic for a number of reasons: - Not all providers do input-input comparison; some do input-state comparison - Not all providers are able to update the last deployed set of inputs when performing a refresh - Some providers--either intentionally or due to bugs--may see changes in resources whose inputs have not changed All of these situations are confusing at the very least, and the first is problematic with respect to correctness. Furthermore, the display code only renders diffs it observes rather than rendering the diffs observed by the provider, which can obscure the actual changes detected at runtime. These changes address both of these issues: - Rather than comparing the current inputs against the last inputs before calling a resource provider's Diff function, the engine calls the Diff function in all cases. - Providers may now return a list of properties that differ between the requested and actual state and the way in which they differ. This information will then be used by the CLI to render the diff appropriately. A provider may also indicate that a particular diff is between old and new inputs rather than old state and new inputs. Fixes #2453.
2019-07-01 21:34:19 +02:00
};
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.CreateRequest.toObject(opt_includeInstance, this);
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CreateRequest} msg The msg instance to transform.
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.toObject = function(includeInstance, msg) {
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
var f, obj = {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
urn: jspb.Message.getFieldWithDefault(msg, 1, ""),
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
properties: (f = msg.getProperties()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
timeout: jspb.Message.getFloatingPointFieldWithDefault(msg, 3, 0.0),
preview: jspb.Message.getBooleanFieldWithDefault(msg, 4, false)
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.CreateRequest}
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.deserializeBinary = function(bytes) {
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.CreateRequest;
return proto.pulumirpc.CreateRequest.deserializeBinaryFromReader(msg, reader);
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CreateRequest} msg The message object to deserialize into.
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.CreateRequest}
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.deserializeBinaryFromReader = function(msg, reader) {
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
Simplify resource provider RPC interface This change simplifies the provider RPC interface slightly: 1) Eliminate Get. We really don't need it anymore. There are several possibly-interesting scenarios down the road that may demand it, but when we get there, we can consider how best to bring this back. Furthermore, the old-style Get remains mostly incompatible with Terraform anyway. 2) Pass URNs, not type tokens, across the RPC boundary. This gives the provider access to more interesting information: the type, still, but also the name (which is no longer an object property).
2017-08-31 22:10:55 +02:00
msg.setUrn(value);
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
break;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
case 2:
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.setProperties(value);
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
break;
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
case 3:
var value = /** @type {number} */ (reader.readDouble());
msg.setTimeout(value);
break;
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
case 4:
var value = /** @type {boolean} */ (reader.readBool());
msg.setPreview(value);
break;
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.prototype.serializeBinary = function() {
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.serializeBinaryToWriter(this, writer);
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CreateRequest} message
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.serializeBinaryToWriter = function(message, writer) {
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
var f = undefined;
Simplify resource provider RPC interface This change simplifies the provider RPC interface slightly: 1) Eliminate Get. We really don't need it anymore. There are several possibly-interesting scenarios down the road that may demand it, but when we get there, we can consider how best to bring this back. Furthermore, the old-style Get remains mostly incompatible with Terraform anyway. 2) Pass URNs, not type tokens, across the RPC boundary. This gives the provider access to more interesting information: the type, still, but also the name (which is no longer an object property).
2017-08-31 22:10:55 +02:00
f = message.getUrn();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
if (f.length > 0) {
writer.writeString(
1,
f
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
);
}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getProperties();
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
if (f != null) {
writer.writeMessage(
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
2,
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
f = message.getTimeout();
if (f !== 0.0) {
writer.writeDouble(
3,
f
);
}
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
f = message.getPreview();
if (f) {
writer.writeBool(
4,
f
);
}
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional string urn = 1;
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
* @return {string}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.prototype.getUrn = function() {
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.CreateRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.prototype.setUrn = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional google.protobuf.Struct properties = 2;
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
* @return {?proto.google.protobuf.Struct}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.prototype.getProperties = function() {
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
return /** @type{?proto.google.protobuf.Struct} */ (
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 2));
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.CreateRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.prototype.setProperties = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 2, value);
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.CreateRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.prototype.clearProperties = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setProperties(undefined);
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateRequest.prototype.hasProperties = function() {
return jspb.Message.getField(this, 2) != null;
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
};
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
/**
* optional double timeout = 3;
* @return {number}
*/
proto.pulumirpc.CreateRequest.prototype.getTimeout = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {number} */ (jspb.Message.getFloatingPointFieldWithDefault(this, 3, 0.0));
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {number} value
* @return {!proto.pulumirpc.CreateRequest} returns this
*/
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
proto.pulumirpc.CreateRequest.prototype.setTimeout = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3FloatField(this, 3, value);
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
};
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
/**
* optional bool preview = 4;
* @return {boolean}
*/
proto.pulumirpc.CreateRequest.prototype.getPreview = function() {
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 4, false));
};
/**
* @param {boolean} value
* @return {!proto.pulumirpc.CreateRequest} returns this
*/
proto.pulumirpc.CreateRequest.prototype.setPreview = function(value) {
return jspb.Message.setProto3BooleanField(this, 4, value);
};
Initial support for output properties (1 of 3) This change includes approximately 1/3rd of the change necessary to support output properties, as per pulumi/lumi#90. In short, the runtime now has a new hidden type, Latent<T>, which represents a "speculative" value, whose eventual type will be T, that we can use during evaluation in various ways. Namely, operations against Latent<T>s generally produce new Latent<U>s. During planning, any Latent<T>s that end up in resource properties are transformed into "unknown" property values. An unknown property value is legal only during planning-time activities, such as Check, Name, and InspectChange. As a result, those RPC interfaces have been updated to include lookaside maps indicating which properties have unknown values. My intent is to add some helper functions to make dealing with this circumstance more correct-by-construction. For now, using an unresolved Latent<T> in a conditional will lead to an error. See pulumi/lumi#67. Speculating beyond these -- by supporting iterative planning and application -- is something we want to support eventually, but it makes sense to do that as an additive change beyond this initial support. That is a missing 1/3. Finally, the other missing 1/3rd which will happen much sooner than the rest is restructuing plan application so that it will correctly observe resolution of Latent<T> values. Right now, the evaluation happens in one single pass, prior to the application, and so Latent<T>s never actually get witnessed in a resolved state.
2017-05-24 02:32:59 +02:00
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.CreateResponse.toObject(opt_includeInstance, this);
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CreateResponse} msg The msg instance to transform.
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.toObject = function(includeInstance, msg) {
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
var f, obj = {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
id: jspb.Message.getFieldWithDefault(msg, 1, ""),
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
properties: (f = msg.getProperties()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f)
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.CreateResponse}
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.deserializeBinary = function(bytes) {
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.CreateResponse;
return proto.pulumirpc.CreateResponse.deserializeBinaryFromReader(msg, reader);
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CreateResponse} msg The message object to deserialize into.
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.CreateResponse}
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.deserializeBinaryFromReader = function(msg, reader) {
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var value = /** @type {string} */ (reader.readString());
msg.setId(value);
break;
case 2:
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setProperties(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.prototype.serializeBinary = function() {
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.serializeBinaryToWriter(this, writer);
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.CreateResponse} message
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.serializeBinaryToWriter = function(message, writer) {
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
var f = undefined;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getId();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
f = message.getProperties();
if (f != null) {
writer.writeMessage(
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
2,
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional string id = 1;
* @return {string}
*/
proto.pulumirpc.CreateResponse.prototype.getId = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.CreateResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.prototype.setId = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
};
/**
* optional google.protobuf.Struct properties = 2;
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
* @return {?proto.google.protobuf.Struct}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.prototype.getProperties = function() {
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
return /** @type{?proto.google.protobuf.Struct} */ (
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 2));
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.CreateResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.prototype.setProperties = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 2, value);
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.CreateResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.prototype.clearProperties = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setProperties(undefined);
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.CreateResponse.prototype.hasProperties = function() {
return jspb.Message.getField(this, 2) != null;
Return state as part of Create and Update¬ As part of the bridge bringup, I've discoverd that the property state returned from Creates does *not* always equal the state that is then read from calls to Get. (I suspect this is a bug and that they should be equivalent, but I doubt it's fruitfal to try and track down all occurrences of this; I bet it's widespread). To cope with this, we will return state from Create and Update, instead of issuing a call to Get. This was a design we considered to start with and frankly didn't have a super strong reason to do it the current way, other than that it seemed elegant to place all of the Get logic in one place. Note that providers may choose to return nil, in which case we will read state from the provider in the usual Get style.
2017-07-18 03:44:45 +02:00
};
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
* @return {!Object}
*/
proto.pulumirpc.ReadRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ReadRequest.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.ReadRequest} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ReadRequest.toObject = function(includeInstance, msg) {
var f, obj = {
id: jspb.Message.getFieldWithDefault(msg, 1, ""),
urn: jspb.Message.getFieldWithDefault(msg, 2, ""),
Refresh inputs (#2531) These changes take advantage of the newly-added support for returning inputs from Read to update a resource's inputs as part of a refresh. As a consequence, the Pulumi engine will now properly detect drift between the actual state of a resource and the desired state described by the program and generate appropriate update or replace steps. As part of these changes, a resource's old inputs are now passed to the provider when performing a refresh. The provider can take advantage of this to maintain the accuracy of any additional data or metadata in the resource's inputs that may need to be updated during the refresh. This is required for the complete implementation of https://github.com/pulumi/pulumi-terraform/pull/349. Without access to the old inputs for a resource, TF-based providers would lose all information about default population during a refresh.
2019-03-11 21:50:00 +01:00
properties: (f = msg.getProperties()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
inputs: (f = msg.getInputs()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f)
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.ReadRequest}
*/
proto.pulumirpc.ReadRequest.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.ReadRequest;
return proto.pulumirpc.ReadRequest.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.ReadRequest} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.ReadRequest}
*/
proto.pulumirpc.ReadRequest.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.setId(value);
break;
case 2:
var value = /** @type {string} */ (reader.readString());
msg.setUrn(value);
break;
case 3:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setProperties(value);
break;
Refresh inputs (#2531) These changes take advantage of the newly-added support for returning inputs from Read to update a resource's inputs as part of a refresh. As a consequence, the Pulumi engine will now properly detect drift between the actual state of a resource and the desired state described by the program and generate appropriate update or replace steps. As part of these changes, a resource's old inputs are now passed to the provider when performing a refresh. The provider can take advantage of this to maintain the accuracy of any additional data or metadata in the resource's inputs that may need to be updated during the refresh. This is required for the complete implementation of https://github.com/pulumi/pulumi-terraform/pull/349. Without access to the old inputs for a resource, TF-based providers would lose all information about default population during a refresh.
2019-03-11 21:50:00 +01:00
case 4:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setInputs(value);
break;
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.ReadRequest.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.ReadRequest.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.ReadRequest} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ReadRequest.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getId();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
f = message.getUrn();
if (f.length > 0) {
writer.writeString(
2,
f
);
}
f = message.getProperties();
if (f != null) {
writer.writeMessage(
3,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Refresh inputs (#2531) These changes take advantage of the newly-added support for returning inputs from Read to update a resource's inputs as part of a refresh. As a consequence, the Pulumi engine will now properly detect drift between the actual state of a resource and the desired state described by the program and generate appropriate update or replace steps. As part of these changes, a resource's old inputs are now passed to the provider when performing a refresh. The provider can take advantage of this to maintain the accuracy of any additional data or metadata in the resource's inputs that may need to be updated during the refresh. This is required for the complete implementation of https://github.com/pulumi/pulumi-terraform/pull/349. Without access to the old inputs for a resource, TF-based providers would lose all information about default population during a refresh.
2019-03-11 21:50:00 +01:00
f = message.getInputs();
if (f != null) {
writer.writeMessage(
4,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
/**
* optional string id = 1;
* @return {string}
*/
proto.pulumirpc.ReadRequest.prototype.getId = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.ReadRequest} returns this
*/
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
proto.pulumirpc.ReadRequest.prototype.setId = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
/**
* optional string urn = 2;
* @return {string}
*/
proto.pulumirpc.ReadRequest.prototype.getUrn = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 2, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.ReadRequest} returns this
*/
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
proto.pulumirpc.ReadRequest.prototype.setUrn = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 2, value);
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
/**
* optional google.protobuf.Struct properties = 3;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.ReadRequest.prototype.getProperties = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 3));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.ReadRequest} returns this
*/
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
proto.pulumirpc.ReadRequest.prototype.setProperties = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 3, value);
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.ReadRequest} returns this
*/
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
proto.pulumirpc.ReadRequest.prototype.clearProperties = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setProperties(undefined);
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
*/
proto.pulumirpc.ReadRequest.prototype.hasProperties = function() {
return jspb.Message.getField(this, 3) != null;
};
Refresh inputs (#2531) These changes take advantage of the newly-added support for returning inputs from Read to update a resource's inputs as part of a refresh. As a consequence, the Pulumi engine will now properly detect drift between the actual state of a resource and the desired state described by the program and generate appropriate update or replace steps. As part of these changes, a resource's old inputs are now passed to the provider when performing a refresh. The provider can take advantage of this to maintain the accuracy of any additional data or metadata in the resource's inputs that may need to be updated during the refresh. This is required for the complete implementation of https://github.com/pulumi/pulumi-terraform/pull/349. Without access to the old inputs for a resource, TF-based providers would lose all information about default population during a refresh.
2019-03-11 21:50:00 +01:00
/**
* optional google.protobuf.Struct inputs = 4;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.ReadRequest.prototype.getInputs = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 4));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.ReadRequest} returns this
*/
Refresh inputs (#2531) These changes take advantage of the newly-added support for returning inputs from Read to update a resource's inputs as part of a refresh. As a consequence, the Pulumi engine will now properly detect drift between the actual state of a resource and the desired state described by the program and generate appropriate update or replace steps. As part of these changes, a resource's old inputs are now passed to the provider when performing a refresh. The provider can take advantage of this to maintain the accuracy of any additional data or metadata in the resource's inputs that may need to be updated during the refresh. This is required for the complete implementation of https://github.com/pulumi/pulumi-terraform/pull/349. Without access to the old inputs for a resource, TF-based providers would lose all information about default population during a refresh.
2019-03-11 21:50:00 +01:00
proto.pulumirpc.ReadRequest.prototype.setInputs = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 4, value);
Refresh inputs (#2531) These changes take advantage of the newly-added support for returning inputs from Read to update a resource's inputs as part of a refresh. As a consequence, the Pulumi engine will now properly detect drift between the actual state of a resource and the desired state described by the program and generate appropriate update or replace steps. As part of these changes, a resource's old inputs are now passed to the provider when performing a refresh. The provider can take advantage of this to maintain the accuracy of any additional data or metadata in the resource's inputs that may need to be updated during the refresh. This is required for the complete implementation of https://github.com/pulumi/pulumi-terraform/pull/349. Without access to the old inputs for a resource, TF-based providers would lose all information about default population during a refresh.
2019-03-11 21:50:00 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.ReadRequest} returns this
*/
Refresh inputs (#2531) These changes take advantage of the newly-added support for returning inputs from Read to update a resource's inputs as part of a refresh. As a consequence, the Pulumi engine will now properly detect drift between the actual state of a resource and the desired state described by the program and generate appropriate update or replace steps. As part of these changes, a resource's old inputs are now passed to the provider when performing a refresh. The provider can take advantage of this to maintain the accuracy of any additional data or metadata in the resource's inputs that may need to be updated during the refresh. This is required for the complete implementation of https://github.com/pulumi/pulumi-terraform/pull/349. Without access to the old inputs for a resource, TF-based providers would lose all information about default population during a refresh.
2019-03-11 21:50:00 +01:00
proto.pulumirpc.ReadRequest.prototype.clearInputs = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setInputs(undefined);
Refresh inputs (#2531) These changes take advantage of the newly-added support for returning inputs from Read to update a resource's inputs as part of a refresh. As a consequence, the Pulumi engine will now properly detect drift between the actual state of a resource and the desired state described by the program and generate appropriate update or replace steps. As part of these changes, a resource's old inputs are now passed to the provider when performing a refresh. The provider can take advantage of this to maintain the accuracy of any additional data or metadata in the resource's inputs that may need to be updated during the refresh. This is required for the complete implementation of https://github.com/pulumi/pulumi-terraform/pull/349. Without access to the old inputs for a resource, TF-based providers would lose all information about default population during a refresh.
2019-03-11 21:50:00 +01:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Refresh inputs (#2531) These changes take advantage of the newly-added support for returning inputs from Read to update a resource's inputs as part of a refresh. As a consequence, the Pulumi engine will now properly detect drift between the actual state of a resource and the desired state described by the program and generate appropriate update or replace steps. As part of these changes, a resource's old inputs are now passed to the provider when performing a refresh. The provider can take advantage of this to maintain the accuracy of any additional data or metadata in the resource's inputs that may need to be updated during the refresh. This is required for the complete implementation of https://github.com/pulumi/pulumi-terraform/pull/349. Without access to the old inputs for a resource, TF-based providers would lose all information about default population during a refresh.
2019-03-11 21:50:00 +01:00
*/
proto.pulumirpc.ReadRequest.prototype.hasInputs = function() {
return jspb.Message.getField(this, 4) != null;
};
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
* @return {!Object}
*/
proto.pulumirpc.ReadResponse.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ReadResponse.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.ReadResponse} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ReadResponse.toObject = function(includeInstance, msg) {
var f, obj = {
Add an ID property to ReadResponse (#1145) The RPC provider interface needs a way to convey back to the engine that a resource being read no longer exists. To do this, we'll return the ID property that was read back. If it is empty, it means the resource is gone. If it is non-empty, we expect it to match the input.
2018-04-10 21:58:50 +02:00
id: jspb.Message.getFieldWithDefault(msg, 1, ""),
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
properties: (f = msg.getProperties()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
inputs: (f = msg.getInputs()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f)
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.ReadResponse}
*/
proto.pulumirpc.ReadResponse.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.ReadResponse;
return proto.pulumirpc.ReadResponse.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.ReadResponse} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.ReadResponse}
*/
proto.pulumirpc.ReadResponse.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
Add an ID property to ReadResponse (#1145) The RPC provider interface needs a way to convey back to the engine that a resource being read no longer exists. To do this, we'll return the ID property that was read back. If it is empty, it means the resource is gone. If it is non-empty, we expect it to match the input.
2018-04-10 21:58:50 +02:00
var value = /** @type {string} */ (reader.readString());
msg.setId(value);
break;
case 2:
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setProperties(value);
break;
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
case 3:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setInputs(value);
break;
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.ReadResponse.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.ReadResponse.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.ReadResponse} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ReadResponse.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
Add an ID property to ReadResponse (#1145) The RPC provider interface needs a way to convey back to the engine that a resource being read no longer exists. To do this, we'll return the ID property that was read back. If it is empty, it means the resource is gone. If it is non-empty, we expect it to match the input.
2018-04-10 21:58:50 +02:00
f = message.getId();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
f = message.getProperties();
if (f != null) {
writer.writeMessage(
Add an ID property to ReadResponse (#1145) The RPC provider interface needs a way to convey back to the engine that a resource being read no longer exists. To do this, we'll return the ID property that was read back. If it is empty, it means the resource is gone. If it is non-empty, we expect it to match the input.
2018-04-10 21:58:50 +02:00
2,
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
f = message.getInputs();
if (f != null) {
writer.writeMessage(
3,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
/**
Add an ID property to ReadResponse (#1145) The RPC provider interface needs a way to convey back to the engine that a resource being read no longer exists. To do this, we'll return the ID property that was read back. If it is empty, it means the resource is gone. If it is non-empty, we expect it to match the input.
2018-04-10 21:58:50 +02:00
* optional string id = 1;
* @return {string}
*/
proto.pulumirpc.ReadResponse.prototype.getId = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.ReadResponse} returns this
*/
Add an ID property to ReadResponse (#1145) The RPC provider interface needs a way to convey back to the engine that a resource being read no longer exists. To do this, we'll return the ID property that was read back. If it is empty, it means the resource is gone. If it is non-empty, we expect it to match the input.
2018-04-10 21:58:50 +02:00
proto.pulumirpc.ReadResponse.prototype.setId = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Add an ID property to ReadResponse (#1145) The RPC provider interface needs a way to convey back to the engine that a resource being read no longer exists. To do this, we'll return the ID property that was read back. If it is empty, it means the resource is gone. If it is non-empty, we expect it to match the input.
2018-04-10 21:58:50 +02:00
};
/**
* optional google.protobuf.Struct properties = 2;
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.ReadResponse.prototype.getProperties = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
Add an ID property to ReadResponse (#1145) The RPC provider interface needs a way to convey back to the engine that a resource being read no longer exists. To do this, we'll return the ID property that was read back. If it is empty, it means the resource is gone. If it is non-empty, we expect it to match the input.
2018-04-10 21:58:50 +02:00
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 2));
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.ReadResponse} returns this
*/
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
proto.pulumirpc.ReadResponse.prototype.setProperties = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 2, value);
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.ReadResponse} returns this
*/
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
proto.pulumirpc.ReadResponse.prototype.clearProperties = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setProperties(undefined);
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
*/
proto.pulumirpc.ReadResponse.prototype.hasProperties = function() {
Add an ID property to ReadResponse (#1145) The RPC provider interface needs a way to convey back to the engine that a resource being read no longer exists. To do this, we'll return the ID property that was read back. If it is empty, it means the resource is gone. If it is non-empty, we expect it to match the input.
2018-04-10 21:58:50 +02:00
return jspb.Message.getField(this, 2) != null;
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
};
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
/**
* optional google.protobuf.Struct inputs = 3;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.ReadResponse.prototype.getInputs = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 3));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.ReadResponse} returns this
*/
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
proto.pulumirpc.ReadResponse.prototype.setInputs = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 3, value);
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.ReadResponse} returns this
*/
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
proto.pulumirpc.ReadResponse.prototype.clearInputs = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setInputs(undefined);
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
*/
proto.pulumirpc.ReadResponse.prototype.hasInputs = function() {
return jspb.Message.getField(this, 3) != null;
};
Make some resource model changes This commit changes two things about our resource model: * Stop performing Pulumi Engine-side diffing of resource state. Instead, we defer to the resource plugins themselves to determine whether a change was made and, if so, the extent of it. This manifests as a simple change to the Diff function; it is done in a backwards compatible way so that we continue with legacy diffing for existing resource provider plugins. * Add a Read RPC method for resource providers. It simply takes a resource's ID and URN, plus an optional bag of further qualifying state, and it returns the current property state as read back from the actual live environment. Note that the optional bag of state must at least include enough additional properties for resources wherein the ID is insufficient for the provider to perform a lookup. It may, however, include the full bag of prior state, for instance in the case of a refresh operation. This is part of pulumi/pulumi#1108.
2018-04-05 16:00:16 +02:00
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.UpdateRequest.repeatedFields_ = [6];
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.UpdateRequest.toObject(opt_includeInstance, this);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.UpdateRequest} msg The msg instance to transform.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.toObject = function(includeInstance, msg) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var f, obj = {
Implement resource provider plugins This change adds basic support for discovering, loading, binding to, and invoking RPC methods on, resource provider plugins. In a nutshell, we add a new context object that will share cached state such as loaded plugins and connections to them. It will be a policy decision in server scenarios how much state to share and between whom. This context also controls per-resource context allocation, which in the future will allow us to perform structured cancellation and teardown amongst entire groups of requests. Plugins are loaded based on their name, and can be found in one of two ways: either simply by having them on your path (with a name of "mu-ressrv-<pkg>", where "<pkg>" is the resource package name with any "/"s replaced with "_"s); or by placing them in the standard library installation location, which need not be on the path for this to work (since we know precisely where to look). If we find a protocol, we will load it as a child process. The protocol for plugins is that they will choose a port on their own -- to eliminate races that'd be involved should Mu attempt to pre-pick one for them -- and then write that out as the first line to STDOUT (terminated by a "\n"). This is the only STDERR/STDOUT that Mu cares about; from there, the plugin is free to write all it pleases (e.g., for logging, debugging purposes, etc). Afterwards, we then bind our gRPC connection to that port, and create a typed resource provider client. The CRUD operations that get driven by plan application are then simple wrappers atop the underlying gRPC calls. For now, we interpret all errors as catastrophic; in the near future, we will probably want to introduce a "structured error" mechanism in the gRPC interface for "transactional errors"; that is, errors for which the server was able to recover to a safe checkpoint, which can be interpreted as ResourceOK rather than ResourceUnknown.
2017-02-19 20:08:06 +01:00
id: jspb.Message.getFieldWithDefault(msg, 1, ""),
Simplify resource provider RPC interface This change simplifies the provider RPC interface slightly: 1) Eliminate Get. We really don't need it anymore. There are several possibly-interesting scenarios down the road that may demand it, but when we get there, we can consider how best to bring this back. Furthermore, the old-style Get remains mostly incompatible with Terraform anyway. 2) Pass URNs, not type tokens, across the RPC boundary. This gives the provider access to more interesting information: the type, still, but also the name (which is no longer an object property).
2017-08-31 22:10:55 +02:00
urn: jspb.Message.getFieldWithDefault(msg, 2, ""),
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
olds: (f = msg.getOlds()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
news: (f = msg.getNews()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
timeout: jspb.Message.getFloatingPointFieldWithDefault(msg, 5, 0.0),
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
ignorechangesList: (f = jspb.Message.getRepeatedField(msg, 6)) == null ? undefined : f,
preview: jspb.Message.getBooleanFieldWithDefault(msg, 7, false)
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.UpdateRequest}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.deserializeBinary = function(bytes) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.UpdateRequest;
return proto.pulumirpc.UpdateRequest.deserializeBinaryFromReader(msg, reader);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.UpdateRequest} msg The message object to deserialize into.
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.UpdateRequest}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.deserializeBinaryFromReader = function(msg, reader) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.setId(value);
break;
Implement resource provider plugins This change adds basic support for discovering, loading, binding to, and invoking RPC methods on, resource provider plugins. In a nutshell, we add a new context object that will share cached state such as loaded plugins and connections to them. It will be a policy decision in server scenarios how much state to share and between whom. This context also controls per-resource context allocation, which in the future will allow us to perform structured cancellation and teardown amongst entire groups of requests. Plugins are loaded based on their name, and can be found in one of two ways: either simply by having them on your path (with a name of "mu-ressrv-<pkg>", where "<pkg>" is the resource package name with any "/"s replaced with "_"s); or by placing them in the standard library installation location, which need not be on the path for this to work (since we know precisely where to look). If we find a protocol, we will load it as a child process. The protocol for plugins is that they will choose a port on their own -- to eliminate races that'd be involved should Mu attempt to pre-pick one for them -- and then write that out as the first line to STDOUT (terminated by a "\n"). This is the only STDERR/STDOUT that Mu cares about; from there, the plugin is free to write all it pleases (e.g., for logging, debugging purposes, etc). Afterwards, we then bind our gRPC connection to that port, and create a typed resource provider client. The CRUD operations that get driven by plan application are then simple wrappers atop the underlying gRPC calls. For now, we interpret all errors as catastrophic; in the near future, we will probably want to introduce a "structured error" mechanism in the gRPC interface for "transactional errors"; that is, errors for which the server was able to recover to a safe checkpoint, which can be interpreted as ResourceOK rather than ResourceUnknown.
2017-02-19 20:08:06 +01:00
case 2:
var value = /** @type {string} */ (reader.readString());
Simplify resource provider RPC interface This change simplifies the provider RPC interface slightly: 1) Eliminate Get. We really don't need it anymore. There are several possibly-interesting scenarios down the road that may demand it, but when we get there, we can consider how best to bring this back. Furthermore, the old-style Get remains mostly incompatible with Terraform anyway. 2) Pass URNs, not type tokens, across the RPC boundary. This gives the provider access to more interesting information: the type, still, but also the name (which is no longer an object property).
2017-08-31 22:10:55 +02:00
msg.setUrn(value);
Implement resource provider plugins This change adds basic support for discovering, loading, binding to, and invoking RPC methods on, resource provider plugins. In a nutshell, we add a new context object that will share cached state such as loaded plugins and connections to them. It will be a policy decision in server scenarios how much state to share and between whom. This context also controls per-resource context allocation, which in the future will allow us to perform structured cancellation and teardown amongst entire groups of requests. Plugins are loaded based on their name, and can be found in one of two ways: either simply by having them on your path (with a name of "mu-ressrv-<pkg>", where "<pkg>" is the resource package name with any "/"s replaced with "_"s); or by placing them in the standard library installation location, which need not be on the path for this to work (since we know precisely where to look). If we find a protocol, we will load it as a child process. The protocol for plugins is that they will choose a port on their own -- to eliminate races that'd be involved should Mu attempt to pre-pick one for them -- and then write that out as the first line to STDOUT (terminated by a "\n"). This is the only STDERR/STDOUT that Mu cares about; from there, the plugin is free to write all it pleases (e.g., for logging, debugging purposes, etc). Afterwards, we then bind our gRPC connection to that port, and create a typed resource provider client. The CRUD operations that get driven by plan application are then simple wrappers atop the underlying gRPC calls. For now, we interpret all errors as catastrophic; in the near future, we will probably want to introduce a "structured error" mechanism in the gRPC interface for "transactional errors"; that is, errors for which the server was able to recover to a safe checkpoint, which can be interpreted as ResourceOK rather than ResourceUnknown.
2017-02-19 20:08:06 +01:00
break;
Pass old state to the provider's API
2017-07-19 16:57:22 +02:00
case 3:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.setOlds(value);
break;
case 4:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setNews(value);
Pass old state to the provider's API
2017-07-19 16:57:22 +02:00
break;
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
case 5:
var value = /** @type {number} */ (reader.readDouble());
msg.setTimeout(value);
break;
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
case 6:
var value = /** @type {string} */ (reader.readString());
msg.addIgnorechanges(value);
break;
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
case 7:
var value = /** @type {boolean} */ (reader.readBool());
msg.setPreview(value);
break;
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.serializeBinary = function() {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.serializeBinaryToWriter(this, writer);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.UpdateRequest} message
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.serializeBinaryToWriter = function(message, writer) {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
var f = undefined;
f = message.getId();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
Simplify resource provider RPC interface This change simplifies the provider RPC interface slightly: 1) Eliminate Get. We really don't need it anymore. There are several possibly-interesting scenarios down the road that may demand it, but when we get there, we can consider how best to bring this back. Furthermore, the old-style Get remains mostly incompatible with Terraform anyway. 2) Pass URNs, not type tokens, across the RPC boundary. This gives the provider access to more interesting information: the type, still, but also the name (which is no longer an object property).
2017-08-31 22:10:55 +02:00
f = message.getUrn();
Implement resource provider plugins This change adds basic support for discovering, loading, binding to, and invoking RPC methods on, resource provider plugins. In a nutshell, we add a new context object that will share cached state such as loaded plugins and connections to them. It will be a policy decision in server scenarios how much state to share and between whom. This context also controls per-resource context allocation, which in the future will allow us to perform structured cancellation and teardown amongst entire groups of requests. Plugins are loaded based on their name, and can be found in one of two ways: either simply by having them on your path (with a name of "mu-ressrv-<pkg>", where "<pkg>" is the resource package name with any "/"s replaced with "_"s); or by placing them in the standard library installation location, which need not be on the path for this to work (since we know precisely where to look). If we find a protocol, we will load it as a child process. The protocol for plugins is that they will choose a port on their own -- to eliminate races that'd be involved should Mu attempt to pre-pick one for them -- and then write that out as the first line to STDOUT (terminated by a "\n"). This is the only STDERR/STDOUT that Mu cares about; from there, the plugin is free to write all it pleases (e.g., for logging, debugging purposes, etc). Afterwards, we then bind our gRPC connection to that port, and create a typed resource provider client. The CRUD operations that get driven by plan application are then simple wrappers atop the underlying gRPC calls. For now, we interpret all errors as catastrophic; in the near future, we will probably want to introduce a "structured error" mechanism in the gRPC interface for "transactional errors"; that is, errors for which the server was able to recover to a safe checkpoint, which can be interpreted as ResourceOK rather than ResourceUnknown.
2017-02-19 20:08:06 +01:00
if (f.length > 0) {
writer.writeString(
2,
f
);
}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getOlds();
Pass old state to the provider's API
2017-07-19 16:57:22 +02:00
if (f != null) {
writer.writeMessage(
3,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getNews();
if (f != null) {
writer.writeMessage(
4,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
f = message.getTimeout();
if (f !== 0.0) {
writer.writeDouble(
5,
f
);
}
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
f = message.getIgnorechangesList();
if (f.length > 0) {
writer.writeRepeatedString(
6,
f
);
}
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
f = message.getPreview();
if (f) {
writer.writeBool(
7,
f
);
}
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
/**
* optional string id = 1;
* @return {string}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.getId = function() {
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.UpdateRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.setId = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Further reshuffle Protobufs; generate JavaScript code After a bit more thinking, we will create new SDK packages for each of the languages we wish to support writing resource providers in. This is where the RPC goo will live, so I have created a new sdk/ directory, moved the Protobuf/gRPC definitions underneath sdk/proto/, and put the generated code into sdk/go/ and sdk/js/.
2017-02-10 18:28:46 +01:00
};
Implement resource provider plugins This change adds basic support for discovering, loading, binding to, and invoking RPC methods on, resource provider plugins. In a nutshell, we add a new context object that will share cached state such as loaded plugins and connections to them. It will be a policy decision in server scenarios how much state to share and between whom. This context also controls per-resource context allocation, which in the future will allow us to perform structured cancellation and teardown amongst entire groups of requests. Plugins are loaded based on their name, and can be found in one of two ways: either simply by having them on your path (with a name of "mu-ressrv-<pkg>", where "<pkg>" is the resource package name with any "/"s replaced with "_"s); or by placing them in the standard library installation location, which need not be on the path for this to work (since we know precisely where to look). If we find a protocol, we will load it as a child process. The protocol for plugins is that they will choose a port on their own -- to eliminate races that'd be involved should Mu attempt to pre-pick one for them -- and then write that out as the first line to STDOUT (terminated by a "\n"). This is the only STDERR/STDOUT that Mu cares about; from there, the plugin is free to write all it pleases (e.g., for logging, debugging purposes, etc). Afterwards, we then bind our gRPC connection to that port, and create a typed resource provider client. The CRUD operations that get driven by plan application are then simple wrappers atop the underlying gRPC calls. For now, we interpret all errors as catastrophic; in the near future, we will probably want to introduce a "structured error" mechanism in the gRPC interface for "transactional errors"; that is, errors for which the server was able to recover to a safe checkpoint, which can be interpreted as ResourceOK rather than ResourceUnknown.
2017-02-19 20:08:06 +01:00
/**
Simplify resource provider RPC interface This change simplifies the provider RPC interface slightly: 1) Eliminate Get. We really don't need it anymore. There are several possibly-interesting scenarios down the road that may demand it, but when we get there, we can consider how best to bring this back. Furthermore, the old-style Get remains mostly incompatible with Terraform anyway. 2) Pass URNs, not type tokens, across the RPC boundary. This gives the provider access to more interesting information: the type, still, but also the name (which is no longer an object property).
2017-08-31 22:10:55 +02:00
* optional string urn = 2;
Implement resource provider plugins This change adds basic support for discovering, loading, binding to, and invoking RPC methods on, resource provider plugins. In a nutshell, we add a new context object that will share cached state such as loaded plugins and connections to them. It will be a policy decision in server scenarios how much state to share and between whom. This context also controls per-resource context allocation, which in the future will allow us to perform structured cancellation and teardown amongst entire groups of requests. Plugins are loaded based on their name, and can be found in one of two ways: either simply by having them on your path (with a name of "mu-ressrv-<pkg>", where "<pkg>" is the resource package name with any "/"s replaced with "_"s); or by placing them in the standard library installation location, which need not be on the path for this to work (since we know precisely where to look). If we find a protocol, we will load it as a child process. The protocol for plugins is that they will choose a port on their own -- to eliminate races that'd be involved should Mu attempt to pre-pick one for them -- and then write that out as the first line to STDOUT (terminated by a "\n"). This is the only STDERR/STDOUT that Mu cares about; from there, the plugin is free to write all it pleases (e.g., for logging, debugging purposes, etc). Afterwards, we then bind our gRPC connection to that port, and create a typed resource provider client. The CRUD operations that get driven by plan application are then simple wrappers atop the underlying gRPC calls. For now, we interpret all errors as catastrophic; in the near future, we will probably want to introduce a "structured error" mechanism in the gRPC interface for "transactional errors"; that is, errors for which the server was able to recover to a safe checkpoint, which can be interpreted as ResourceOK rather than ResourceUnknown.
2017-02-19 20:08:06 +01:00
* @return {string}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.getUrn = function() {
Implement resource provider plugins This change adds basic support for discovering, loading, binding to, and invoking RPC methods on, resource provider plugins. In a nutshell, we add a new context object that will share cached state such as loaded plugins and connections to them. It will be a policy decision in server scenarios how much state to share and between whom. This context also controls per-resource context allocation, which in the future will allow us to perform structured cancellation and teardown amongst entire groups of requests. Plugins are loaded based on their name, and can be found in one of two ways: either simply by having them on your path (with a name of "mu-ressrv-<pkg>", where "<pkg>" is the resource package name with any "/"s replaced with "_"s); or by placing them in the standard library installation location, which need not be on the path for this to work (since we know precisely where to look). If we find a protocol, we will load it as a child process. The protocol for plugins is that they will choose a port on their own -- to eliminate races that'd be involved should Mu attempt to pre-pick one for them -- and then write that out as the first line to STDOUT (terminated by a "\n"). This is the only STDERR/STDOUT that Mu cares about; from there, the plugin is free to write all it pleases (e.g., for logging, debugging purposes, etc). Afterwards, we then bind our gRPC connection to that port, and create a typed resource provider client. The CRUD operations that get driven by plan application are then simple wrappers atop the underlying gRPC calls. For now, we interpret all errors as catastrophic; in the near future, we will probably want to introduce a "structured error" mechanism in the gRPC interface for "transactional errors"; that is, errors for which the server was able to recover to a safe checkpoint, which can be interpreted as ResourceOK rather than ResourceUnknown.
2017-02-19 20:08:06 +01:00
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 2, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.UpdateRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.setUrn = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 2, value);
Implement resource provider plugins This change adds basic support for discovering, loading, binding to, and invoking RPC methods on, resource provider plugins. In a nutshell, we add a new context object that will share cached state such as loaded plugins and connections to them. It will be a policy decision in server scenarios how much state to share and between whom. This context also controls per-resource context allocation, which in the future will allow us to perform structured cancellation and teardown amongst entire groups of requests. Plugins are loaded based on their name, and can be found in one of two ways: either simply by having them on your path (with a name of "mu-ressrv-<pkg>", where "<pkg>" is the resource package name with any "/"s replaced with "_"s); or by placing them in the standard library installation location, which need not be on the path for this to work (since we know precisely where to look). If we find a protocol, we will load it as a child process. The protocol for plugins is that they will choose a port on their own -- to eliminate races that'd be involved should Mu attempt to pre-pick one for them -- and then write that out as the first line to STDOUT (terminated by a "\n"). This is the only STDERR/STDOUT that Mu cares about; from there, the plugin is free to write all it pleases (e.g., for logging, debugging purposes, etc). Afterwards, we then bind our gRPC connection to that port, and create a typed resource provider client. The CRUD operations that get driven by plan application are then simple wrappers atop the underlying gRPC calls. For now, we interpret all errors as catastrophic; in the near future, we will probably want to introduce a "structured error" mechanism in the gRPC interface for "transactional errors"; that is, errors for which the server was able to recover to a safe checkpoint, which can be interpreted as ResourceOK rather than ResourceUnknown.
2017-02-19 20:08:06 +01:00
};
Pass old state to the provider's API
2017-07-19 16:57:22 +02:00
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional google.protobuf.Struct olds = 3;
Pass old state to the provider's API
2017-07-19 16:57:22 +02:00
* @return {?proto.google.protobuf.Struct}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.getOlds = function() {
Pass old state to the provider's API
2017-07-19 16:57:22 +02:00
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 3));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.UpdateRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.setOlds = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 3, value);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.UpdateRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.clearOlds = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setOlds(undefined);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
*/
proto.pulumirpc.UpdateRequest.prototype.hasOlds = function() {
return jspb.Message.getField(this, 3) != null;
};
/**
* optional google.protobuf.Struct news = 4;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.UpdateRequest.prototype.getNews = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 4));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.UpdateRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.setNews = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 4, value);
Pass old state to the provider's API
2017-07-19 16:57:22 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.UpdateRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.clearNews = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setNews(undefined);
Pass old state to the provider's API
2017-07-19 16:57:22 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Pass old state to the provider's API
2017-07-19 16:57:22 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateRequest.prototype.hasNews = function() {
return jspb.Message.getField(this, 4) != null;
Pass old state to the provider's API
2017-07-19 16:57:22 +02:00
};
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
/**
* optional double timeout = 5;
* @return {number}
*/
proto.pulumirpc.UpdateRequest.prototype.getTimeout = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {number} */ (jspb.Message.getFloatingPointFieldWithDefault(this, 5, 0.0));
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {number} value
* @return {!proto.pulumirpc.UpdateRequest} returns this
*/
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
proto.pulumirpc.UpdateRequest.prototype.setTimeout = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3FloatField(this, 5, value);
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
};
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
/**
* repeated string ignoreChanges = 6;
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!Array<string>}
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
*/
proto.pulumirpc.UpdateRequest.prototype.getIgnorechangesList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 6));
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.UpdateRequest} returns this
*/
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
proto.pulumirpc.UpdateRequest.prototype.setIgnorechangesList = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setField(this, 6, value || []);
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
};
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {string} value
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
* @param {number=} opt_index
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!proto.pulumirpc.UpdateRequest} returns this
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
*/
proto.pulumirpc.UpdateRequest.prototype.addIgnorechanges = function(value, opt_index) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.addToRepeatedField(this, 6, value, opt_index);
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.UpdateRequest} returns this
*/
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
proto.pulumirpc.UpdateRequest.prototype.clearIgnorechangesList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setIgnorechangesList([]);
Pass ignoreChanges to providers. (#3005) These changes add support for passing `ignoreChanges` paths to resource providers. This is intended to accommodate providers that perform diffs between resource inputs and resource state (e.g. all Terraform-based providers, the k8s provider when using API server dry-runs). These paths are specified using the same syntax as the paths used in detailed diffs. In addition to passing these paths to providers, the existing support for `ignoreChanges` in inputs has been extended to accept paths rather than top-level keys. It is an error to specify a path that is missing one or more component in the old or new inputs. Fixes #2936, #2663.
2019-07-31 18:39:07 +02:00
};
Add support for provider-side preview. (#5443) These changes add support for provider-side previews of create and update operations, which allows resource providers to supply output property values for resources that are being created or updated during a preview. If a plugin supports provider-side preview, its create/update methods will be invoked during previews with the `preview` property set to true. It is the responsibility of the provider to fill in any output properties that are known before returning. It is a best practice for providers to only fill in property values that are guaranteed to be identical if the preview were instead an update (i.e. only those output properties whose values can be conclusively determined without actually performing the create/update operation should be populated). Providers that support previews must accept unknown values in their create and update methods. If a plugin does not support provider-side preview, the inputs to a create or update operation will be propagated to the outputs as they are today. Fixes #4992.
2020-10-09 22:13:55 +02:00
/**
* optional bool preview = 7;
* @return {boolean}
*/
proto.pulumirpc.UpdateRequest.prototype.getPreview = function() {
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 7, false));
};
/**
* @param {boolean} value
* @return {!proto.pulumirpc.UpdateRequest} returns this
*/
proto.pulumirpc.UpdateRequest.prototype.setPreview = function(value) {
return jspb.Message.setProto3BooleanField(this, 7, value);
};
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.UpdateResponse.toObject(opt_includeInstance, this);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.UpdateResponse} msg The msg instance to transform.
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.toObject = function(includeInstance, msg) {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
var f, obj = {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
properties: (f = msg.getProperties()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f)
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.UpdateResponse}
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.deserializeBinary = function(bytes) {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.UpdateResponse;
return proto.pulumirpc.UpdateResponse.deserializeBinaryFromReader(msg, reader);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.UpdateResponse} msg The message object to deserialize into.
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.UpdateResponse}
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.deserializeBinaryFromReader = function(msg, reader) {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
msg.setProperties(value);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.prototype.serializeBinary = function() {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.serializeBinaryToWriter(this, writer);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.UpdateResponse} message
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.serializeBinaryToWriter = function(message, writer) {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
var f = undefined;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getProperties();
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
if (f != null) {
writer.writeMessage(
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
1,
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional google.protobuf.Struct properties = 1;
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* @return {?proto.google.protobuf.Struct}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.prototype.getProperties = function() {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
return /** @type{?proto.google.protobuf.Struct} */ (
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 1));
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.UpdateResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.prototype.setProperties = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 1, value);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.UpdateResponse} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.prototype.clearProperties = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setProperties(undefined);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.UpdateResponse.prototype.hasProperties = function() {
return jspb.Message.getField(this, 1) != null;
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* @return {!Object}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.DeleteRequest.toObject(opt_includeInstance, this);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* http://goto/soy-param-migration
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.DeleteRequest} msg The msg instance to transform.
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* @return {!Object}
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.toObject = function(includeInstance, msg) {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
var f, obj = {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
id: jspb.Message.getFieldWithDefault(msg, 1, ""),
urn: jspb.Message.getFieldWithDefault(msg, 2, ""),
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
properties: (f = msg.getProperties()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
timeout: jspb.Message.getFloatingPointFieldWithDefault(msg, 4, 0.0)
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.DeleteRequest}
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.deserializeBinary = function(bytes) {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
var reader = new jspb.BinaryReader(bytes);
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var msg = new proto.pulumirpc.DeleteRequest;
return proto.pulumirpc.DeleteRequest.deserializeBinaryFromReader(msg, reader);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.DeleteRequest} msg The message object to deserialize into.
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @return {!proto.pulumirpc.DeleteRequest}
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.deserializeBinaryFromReader = function(msg, reader) {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var value = /** @type {string} */ (reader.readString());
msg.setId(value);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
break;
case 2:
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
var value = /** @type {string} */ (reader.readString());
msg.setUrn(value);
break;
case 3:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setProperties(value);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
break;
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
case 4:
var value = /** @type {number} */ (reader.readDouble());
msg.setTimeout(value);
break;
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.prototype.serializeBinary = function() {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
var writer = new jspb.BinaryWriter();
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.serializeBinaryToWriter(this, writer);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* @param {!proto.pulumirpc.DeleteRequest} message
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
* @param {!jspb.BinaryWriter} writer
Implement components This change implements core support for "components" in the Pulumi Fabric. This work is described further in pulumi/pulumi#340, where we are still discussing some of the finer points. In a nutshell, resources no longer imply external providers. It's entirely possible to have a resource that logically represents something but without having a physical manifestation that needs to be tracked and managed by our typical CRUD operations. For example, the aws/serverless/Function helper is one such type. It aggregates Lambda-related resources and exposes a nice interface. All of the Pulumi Cloud Framework resources are also examples. To indicate that a resource does participate in the usual CRUD resource provider, it simply derives from ExternalResource instead of Resource. All resources now have the ability to adopt children. This is purely a metadata/tagging thing, and will help us roll up displays, provide attribution to the developer, and even hide aspects of the resource graph as appropriate (e.g., when they are implementation details). Our use of this capability is ultra limited right now; in fact, the only place we display children is in the CLI output. For instance: + aws:serverless:Function: (create) [urn=urn:pulumi:demo::serverless::aws:serverless:Function::mylambda] => urn:pulumi:demo::serverless::aws:iam/role:Role::mylambda-iamrole => urn:pulumi:demo::serverless::aws:iam/rolePolicyAttachment:RolePolicyAttachment::mylambda-iampolicy-0 => urn:pulumi:demo::serverless::aws:lambda/function:Function::mylambda The bit indicating whether a resource is external or not is tracked in the resulting checkpoint file, along with any of its children.
2017-10-14 23:18:43 +02:00
* @suppress {unusedLocalVariables} f is only used for nested messages
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.serializeBinaryToWriter = function(message, writer) {
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
var f = undefined;
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getId();
if (f.length > 0) {
writer.writeString(
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
1,
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
);
}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f = message.getUrn();
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
if (f.length > 0) {
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
writer.writeString(
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
2,
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
f
);
}
f = message.getProperties();
if (f != null) {
writer.writeMessage(
3,
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
f,
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
);
}
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
f = message.getTimeout();
if (f !== 0.0) {
writer.writeDouble(
4,
f
);
}
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional string id = 1;
* @return {string}
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.prototype.getId = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.DeleteRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.prototype.setId = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
/**
* optional string urn = 2;
* @return {string}
*/
proto.pulumirpc.DeleteRequest.prototype.getUrn = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 2, ""));
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.DeleteRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.prototype.setUrn = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 2, value);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
/**
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
* optional google.protobuf.Struct properties = 3;
* @return {?proto.google.protobuf.Struct}
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.prototype.getProperties = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 3));
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.DeleteRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.prototype.setProperties = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 3, value);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.DeleteRequest} returns this
*/
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
proto.pulumirpc.DeleteRequest.prototype.clearProperties = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setProperties(undefined);
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Add a notion of stable properties This change adds the capability for a resource provider to indicate that, where an action carried out in response to a diff, a certain set of properties would be "stable"; that is to say, they are guaranteed not to change. As a result, properties may be resolved to their final values during previewing, avoiding erroneous cascading impacts. This avoids the ever-annoying situation I keep running into when demoing: when adding or removing an ingress rule to a security group, we ripple the impact through the instance, and claim it must be replaced, because that instance depends on the security group via its name. Well, the name is a great example of a stable property, in that it will never change, and so this is truly unfortunate and always adds uncertainty into the demos. Particularly since the actual update doesn't need to perform replacements. This resolves pulumi/pulumi#330.
2017-10-04 14:22:21 +02:00
*/
proto.pulumirpc.DeleteRequest.prototype.hasProperties = function() {
return jspb.Message.getField(this, 3) != null;
Add an Invoke RPC method on ResourceProvider This change enables us to make progress on exposing data sources (see pulumi/pulumi-terraform#29). The idea is to have an Invoke function that simply takes a function token and arguments, performs the function lookup and invocation, and then returns a return value.
2017-09-20 02:23:10 +02:00
};
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
/**
* optional double timeout = 4;
* @return {number}
*/
proto.pulumirpc.DeleteRequest.prototype.getTimeout = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {number} */ (jspb.Message.getFloatingPointFieldWithDefault(this, 4, 0.0));
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {number} value
* @return {!proto.pulumirpc.DeleteRequest} returns this
*/
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
proto.pulumirpc.DeleteRequest.prototype.setTimeout = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3FloatField(this, 4, value);
Addition of Custom Timeouts (#2885) * Plumbing the custom timeouts from the engine to the providers * Plumbing the CustomTimeouts through to the engine and adding test to show this * Change the provider proto to include individual timeouts * Plumbing the CustomTimeouts from the engine through to the Provider RPC interface * Change how the CustomTimeouts are sent across RPC These errors were spotted in testing. We can now see that the timeout information is arriving in the RegisterResourceRequest ``` req=&pulumirpc.RegisterResourceRequest{ Type: "aws:s3/bucket:Bucket", Name: "my-bucket", Parent: "urn:pulumi:dev::aws-vpc::pulumi:pulumi:Stack::aws-vpc-dev", Custom: true, Object: &structpb.Struct{}, Protect: false, Dependencies: nil, Provider: "", PropertyDependencies: {}, DeleteBeforeReplace: false, Version: "", IgnoreChanges: nil, AcceptSecrets: true, AdditionalSecretOutputs: nil, Aliases: nil, CustomTimeouts: &pulumirpc.RegisterResourceRequest_CustomTimeouts{ Create: 300, Update: 400, Delete: 500, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, }, XXX_NoUnkeyedLiteral: struct {}{}, XXX_unrecognized: nil, XXX_sizecache: 0, } ``` * Changing the design to use strings * CHANGELOG entry to include the CustomTimeouts work * Changing custom timeouts to be passed around the engine as converted value We don't want to pass around strings - the user can provide it but we want to make the engine aware of the timeout in seconds as a float64
2019-07-15 23:26:28 +02:00
};
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
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 04:33:55 +02:00
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
Include config secret info in Construct calls (#7358)
2021-06-25 00:38:01 +02:00
proto.pulumirpc.ConstructRequest.repeatedFields_ = [14,15,16];
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 04:33:55 +02:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
* Creates an object representation of this proto.
* Field names that are reserved in JavaScript and will be renamed to pb_name.
* Optional fields that are not set will be set to undefined.
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @return {!Object}
*/
proto.pulumirpc.ConstructRequest.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ConstructRequest.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.ConstructRequest} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConstructRequest.toObject = function(includeInstance, msg) {
var f, obj = {
project: jspb.Message.getFieldWithDefault(msg, 1, ""),
stack: jspb.Message.getFieldWithDefault(msg, 2, ""),
configMap: (f = msg.getConfigMap()) ? f.toObject(includeInstance, undefined) : [],
dryrun: jspb.Message.getBooleanFieldWithDefault(msg, 4, false),
parallel: jspb.Message.getFieldWithDefault(msg, 5, 0),
monitorendpoint: jspb.Message.getFieldWithDefault(msg, 6, ""),
type: jspb.Message.getFieldWithDefault(msg, 7, ""),
name: jspb.Message.getFieldWithDefault(msg, 8, ""),
parent: jspb.Message.getFieldWithDefault(msg, 9, ""),
inputs: (f = msg.getInputs()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
inputdependenciesMap: (f = msg.getInputdependenciesMap()) ? f.toObject(includeInstance, proto.pulumirpc.ConstructRequest.PropertyDependencies.toObject) : [],
protect: jspb.Message.getBooleanFieldWithDefault(msg, 12, false),
providersMap: (f = msg.getProvidersMap()) ? f.toObject(includeInstance, undefined) : [],
aliasesList: (f = jspb.Message.getRepeatedField(msg, 14)) == null ? undefined : f,
Include config secret info in Construct calls (#7358)
2021-06-25 00:38:01 +02:00
dependenciesList: (f = jspb.Message.getRepeatedField(msg, 15)) == null ? undefined : f,
configsecretkeysList: (f = jspb.Message.getRepeatedField(msg, 16)) == null ? undefined : f
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 04:33:55 +02:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.ConstructRequest}
*/
proto.pulumirpc.ConstructRequest.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.ConstructRequest;
return proto.pulumirpc.ConstructRequest.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.ConstructRequest} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.ConstructRequest}
*/
proto.pulumirpc.ConstructRequest.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.setProject(value);
break;
case 2:
var value = /** @type {string} */ (reader.readString());
msg.setStack(value);
break;
case 3:
var value = msg.getConfigMap();
reader.readMessage(value, function(message, reader) {
jspb.Map.deserializeBinary(message, reader, jspb.BinaryReader.prototype.readString, jspb.BinaryReader.prototype.readString, null, "", "");
});
break;
case 4:
var value = /** @type {boolean} */ (reader.readBool());
msg.setDryrun(value);
break;
case 5:
var value = /** @type {number} */ (reader.readInt32());
msg.setParallel(value);
break;
case 6:
var value = /** @type {string} */ (reader.readString());
msg.setMonitorendpoint(value);
break;
case 7:
var value = /** @type {string} */ (reader.readString());
msg.setType(value);
break;
case 8:
var value = /** @type {string} */ (reader.readString());
msg.setName(value);
break;
case 9:
var value = /** @type {string} */ (reader.readString());
msg.setParent(value);
break;
case 10:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setInputs(value);
break;
case 11:
var value = msg.getInputdependenciesMap();
reader.readMessage(value, function(message, reader) {
jspb.Map.deserializeBinary(message, reader, jspb.BinaryReader.prototype.readString, jspb.BinaryReader.prototype.readMessage, proto.pulumirpc.ConstructRequest.PropertyDependencies.deserializeBinaryFromReader, "", new proto.pulumirpc.ConstructRequest.PropertyDependencies());
});
break;
case 12:
var value = /** @type {boolean} */ (reader.readBool());
msg.setProtect(value);
break;
case 13:
var value = msg.getProvidersMap();
reader.readMessage(value, function(message, reader) {
jspb.Map.deserializeBinary(message, reader, jspb.BinaryReader.prototype.readString, jspb.BinaryReader.prototype.readString, null, "", "");
});
break;
case 14:
var value = /** @type {string} */ (reader.readString());
msg.addAliases(value);
break;
case 15:
var value = /** @type {string} */ (reader.readString());
msg.addDependencies(value);
break;
Include config secret info in Construct calls (#7358)
2021-06-25 00:38:01 +02:00
case 16:
var value = /** @type {string} */ (reader.readString());
msg.addConfigsecretkeys(value);
break;
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 04:33:55 +02:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.ConstructRequest.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.ConstructRequest.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.ConstructRequest} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConstructRequest.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getProject();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
f = message.getStack();
if (f.length > 0) {
writer.writeString(
2,
f
);
}
f = message.getConfigMap(true);
if (f && f.getLength() > 0) {
f.serializeBinary(3, writer, jspb.BinaryWriter.prototype.writeString, jspb.BinaryWriter.prototype.writeString);
}
f = message.getDryrun();
if (f) {
writer.writeBool(
4,
f
);
}
f = message.getParallel();
if (f !== 0) {
writer.writeInt32(
5,
f
);
}
f = message.getMonitorendpoint();
if (f.length > 0) {
writer.writeString(
6,
f
);
}
f = message.getType();
if (f.length > 0) {
writer.writeString(
7,
f
);
}
f = message.getName();
if (f.length > 0) {
writer.writeString(
8,
f
);
}
f = message.getParent();
if (f.length > 0) {
writer.writeString(
9,
f
);
}
f = message.getInputs();
if (f != null) {
writer.writeMessage(
10,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
f = message.getInputdependenciesMap(true);
if (f && f.getLength() > 0) {
f.serializeBinary(11, writer, jspb.BinaryWriter.prototype.writeString, jspb.BinaryWriter.prototype.writeMessage, proto.pulumirpc.ConstructRequest.PropertyDependencies.serializeBinaryToWriter);
}
f = message.getProtect();
if (f) {
writer.writeBool(
12,
f
);
}
f = message.getProvidersMap(true);
if (f && f.getLength() > 0) {
f.serializeBinary(13, writer, jspb.BinaryWriter.prototype.writeString, jspb.BinaryWriter.prototype.writeString);
}
f = message.getAliasesList();
if (f.length > 0) {
writer.writeRepeatedString(
14,
f
);
}
f = message.getDependenciesList();
if (f.length > 0) {
writer.writeRepeatedString(
15,
f
);
}
Include config secret info in Construct calls (#7358)
2021-06-25 00:38:01 +02:00
f = message.getConfigsecretkeysList();
if (f.length > 0) {
writer.writeRepeatedString(
16,
f
);
}
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 04:33:55 +02:00
};
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.repeatedFields_ = [1];
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
* Creates an object representation of this proto.
* Field names that are reserved in JavaScript and will be renamed to pb_name.
* Optional fields that are not set will be set to undefined.
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @return {!Object}
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ConstructRequest.PropertyDependencies.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.ConstructRequest.PropertyDependencies} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.toObject = function(includeInstance, msg) {
var f, obj = {
urnsList: (f = jspb.Message.getRepeatedField(msg, 1)) == null ? undefined : f
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.ConstructRequest.PropertyDependencies}
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.ConstructRequest.PropertyDependencies;
return proto.pulumirpc.ConstructRequest.PropertyDependencies.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.ConstructRequest.PropertyDependencies} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.ConstructRequest.PropertyDependencies}
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.addUrns(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.ConstructRequest.PropertyDependencies.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.ConstructRequest.PropertyDependencies} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getUrnsList();
if (f.length > 0) {
writer.writeRepeatedString(
1,
f
);
}
};
/**
* repeated string urns = 1;
* @return {!Array<string>}
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.prototype.getUrnsList = function() {
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 1));
};
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.ConstructRequest.PropertyDependencies} returns this
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.prototype.setUrnsList = function(value) {
return jspb.Message.setField(this, 1, value || []);
};
/**
* @param {string} value
* @param {number=} opt_index
* @return {!proto.pulumirpc.ConstructRequest.PropertyDependencies} returns this
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.prototype.addUrns = function(value, opt_index) {
return jspb.Message.addToRepeatedField(this, 1, value, opt_index);
};
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.ConstructRequest.PropertyDependencies} returns this
*/
proto.pulumirpc.ConstructRequest.PropertyDependencies.prototype.clearUrnsList = function() {
return this.setUrnsList([]);
};
/**
* optional string project = 1;
* @return {string}
*/
proto.pulumirpc.ConstructRequest.prototype.getProject = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setProject = function(value) {
return jspb.Message.setProto3StringField(this, 1, value);
};
/**
* optional string stack = 2;
* @return {string}
*/
proto.pulumirpc.ConstructRequest.prototype.getStack = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 2, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setStack = function(value) {
return jspb.Message.setProto3StringField(this, 2, value);
};
/**
* map<string, string> config = 3;
* @param {boolean=} opt_noLazyCreate Do not create the map if
* empty, instead returning `undefined`
* @return {!jspb.Map<string,string>}
*/
proto.pulumirpc.ConstructRequest.prototype.getConfigMap = function(opt_noLazyCreate) {
return /** @type {!jspb.Map<string,string>} */ (
jspb.Message.getMapField(this, 3, opt_noLazyCreate,
null));
};
/**
* Clears values from the map. The map will be non-null.
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.clearConfigMap = function() {
this.getConfigMap().clear();
return this;};
/**
* optional bool dryRun = 4;
* @return {boolean}
*/
proto.pulumirpc.ConstructRequest.prototype.getDryrun = function() {
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 4, false));
};
/**
* @param {boolean} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setDryrun = function(value) {
return jspb.Message.setProto3BooleanField(this, 4, value);
};
/**
* optional int32 parallel = 5;
* @return {number}
*/
proto.pulumirpc.ConstructRequest.prototype.getParallel = function() {
return /** @type {number} */ (jspb.Message.getFieldWithDefault(this, 5, 0));
};
/**
* @param {number} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setParallel = function(value) {
return jspb.Message.setProto3IntField(this, 5, value);
};
/**
* optional string monitorEndpoint = 6;
* @return {string}
*/
proto.pulumirpc.ConstructRequest.prototype.getMonitorendpoint = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 6, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setMonitorendpoint = function(value) {
return jspb.Message.setProto3StringField(this, 6, value);
};
/**
* optional string type = 7;
* @return {string}
*/
proto.pulumirpc.ConstructRequest.prototype.getType = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 7, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setType = function(value) {
return jspb.Message.setProto3StringField(this, 7, value);
};
/**
* optional string name = 8;
* @return {string}
*/
proto.pulumirpc.ConstructRequest.prototype.getName = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 8, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setName = function(value) {
return jspb.Message.setProto3StringField(this, 8, value);
};
/**
* optional string parent = 9;
* @return {string}
*/
proto.pulumirpc.ConstructRequest.prototype.getParent = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 9, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setParent = function(value) {
return jspb.Message.setProto3StringField(this, 9, value);
};
/**
* optional google.protobuf.Struct inputs = 10;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.ConstructRequest.prototype.getInputs = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 10));
};
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setInputs = function(value) {
return jspb.Message.setWrapperField(this, 10, value);
};
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.clearInputs = function() {
return this.setInputs(undefined);
};
/**
* Returns whether this field is set.
* @return {boolean}
*/
proto.pulumirpc.ConstructRequest.prototype.hasInputs = function() {
return jspb.Message.getField(this, 10) != null;
};
/**
* map<string, PropertyDependencies> inputDependencies = 11;
* @param {boolean=} opt_noLazyCreate Do not create the map if
* empty, instead returning `undefined`
* @return {!jspb.Map<string,!proto.pulumirpc.ConstructRequest.PropertyDependencies>}
*/
proto.pulumirpc.ConstructRequest.prototype.getInputdependenciesMap = function(opt_noLazyCreate) {
return /** @type {!jspb.Map<string,!proto.pulumirpc.ConstructRequest.PropertyDependencies>} */ (
jspb.Message.getMapField(this, 11, opt_noLazyCreate,
proto.pulumirpc.ConstructRequest.PropertyDependencies));
};
/**
* Clears values from the map. The map will be non-null.
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.clearInputdependenciesMap = function() {
this.getInputdependenciesMap().clear();
return this;};
/**
* optional bool protect = 12;
* @return {boolean}
*/
proto.pulumirpc.ConstructRequest.prototype.getProtect = function() {
return /** @type {boolean} */ (jspb.Message.getBooleanFieldWithDefault(this, 12, false));
};
/**
* @param {boolean} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setProtect = function(value) {
return jspb.Message.setProto3BooleanField(this, 12, value);
};
/**
* map<string, string> providers = 13;
* @param {boolean=} opt_noLazyCreate Do not create the map if
* empty, instead returning `undefined`
* @return {!jspb.Map<string,string>}
*/
proto.pulumirpc.ConstructRequest.prototype.getProvidersMap = function(opt_noLazyCreate) {
return /** @type {!jspb.Map<string,string>} */ (
jspb.Message.getMapField(this, 13, opt_noLazyCreate,
null));
};
/**
* Clears values from the map. The map will be non-null.
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.clearProvidersMap = function() {
this.getProvidersMap().clear();
return this;};
/**
* repeated string aliases = 14;
* @return {!Array<string>}
*/
proto.pulumirpc.ConstructRequest.prototype.getAliasesList = function() {
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 14));
};
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setAliasesList = function(value) {
return jspb.Message.setField(this, 14, value || []);
};
/**
* @param {string} value
* @param {number=} opt_index
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.addAliases = function(value, opt_index) {
return jspb.Message.addToRepeatedField(this, 14, value, opt_index);
};
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.clearAliasesList = function() {
return this.setAliasesList([]);
};
/**
* repeated string dependencies = 15;
* @return {!Array<string>}
*/
proto.pulumirpc.ConstructRequest.prototype.getDependenciesList = function() {
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 15));
};
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setDependenciesList = function(value) {
return jspb.Message.setField(this, 15, value || []);
};
/**
* @param {string} value
* @param {number=} opt_index
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.addDependencies = function(value, opt_index) {
return jspb.Message.addToRepeatedField(this, 15, value, opt_index);
};
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.clearDependenciesList = function() {
return this.setDependenciesList([]);
};
Include config secret info in Construct calls (#7358)
2021-06-25 00:38:01 +02:00
/**
* repeated string configSecretKeys = 16;
* @return {!Array<string>}
*/
proto.pulumirpc.ConstructRequest.prototype.getConfigsecretkeysList = function() {
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 16));
};
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.setConfigsecretkeysList = function(value) {
return jspb.Message.setField(this, 16, value || []);
};
/**
* @param {string} value
* @param {number=} opt_index
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.addConfigsecretkeys = function(value, opt_index) {
return jspb.Message.addToRepeatedField(this, 16, value, opt_index);
};
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.ConstructRequest} returns this
*/
proto.pulumirpc.ConstructRequest.prototype.clearConfigsecretkeysList = function() {
return this.setConfigsecretkeysList([]);
};
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 04:33:55 +02:00
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
* Creates an object representation of this proto.
* Field names that are reserved in JavaScript and will be renamed to pb_name.
* Optional fields that are not set will be set to undefined.
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @return {!Object}
*/
proto.pulumirpc.ConstructResponse.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ConstructResponse.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.ConstructResponse} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConstructResponse.toObject = function(includeInstance, msg) {
var f, obj = {
urn: jspb.Message.getFieldWithDefault(msg, 1, ""),
state: (f = msg.getState()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
statedependenciesMap: (f = msg.getStatedependenciesMap()) ? f.toObject(includeInstance, proto.pulumirpc.ConstructResponse.PropertyDependencies.toObject) : []
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.ConstructResponse}
*/
proto.pulumirpc.ConstructResponse.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.ConstructResponse;
return proto.pulumirpc.ConstructResponse.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.ConstructResponse} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.ConstructResponse}
*/
proto.pulumirpc.ConstructResponse.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.setUrn(value);
break;
case 2:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setState(value);
break;
case 3:
var value = msg.getStatedependenciesMap();
reader.readMessage(value, function(message, reader) {
jspb.Map.deserializeBinary(message, reader, jspb.BinaryReader.prototype.readString, jspb.BinaryReader.prototype.readMessage, proto.pulumirpc.ConstructResponse.PropertyDependencies.deserializeBinaryFromReader, "", new proto.pulumirpc.ConstructResponse.PropertyDependencies());
});
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.ConstructResponse.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.ConstructResponse.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.ConstructResponse} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConstructResponse.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getUrn();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
f = message.getState();
if (f != null) {
writer.writeMessage(
2,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
f = message.getStatedependenciesMap(true);
if (f && f.getLength() > 0) {
f.serializeBinary(3, writer, jspb.BinaryWriter.prototype.writeString, jspb.BinaryWriter.prototype.writeMessage, proto.pulumirpc.ConstructResponse.PropertyDependencies.serializeBinaryToWriter);
}
};
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.repeatedFields_ = [1];
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
* Creates an object representation of this proto.
* Field names that are reserved in JavaScript and will be renamed to pb_name.
* Optional fields that are not set will be set to undefined.
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @return {!Object}
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ConstructResponse.PropertyDependencies.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.ConstructResponse.PropertyDependencies} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.toObject = function(includeInstance, msg) {
var f, obj = {
urnsList: (f = jspb.Message.getRepeatedField(msg, 1)) == null ? undefined : f
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.ConstructResponse.PropertyDependencies}
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.ConstructResponse.PropertyDependencies;
return proto.pulumirpc.ConstructResponse.PropertyDependencies.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.ConstructResponse.PropertyDependencies} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.ConstructResponse.PropertyDependencies}
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.addUrns(value);
break;
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.ConstructResponse.PropertyDependencies.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.ConstructResponse.PropertyDependencies} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getUrnsList();
if (f.length > 0) {
writer.writeRepeatedString(
1,
f
);
}
};
/**
* repeated string urns = 1;
* @return {!Array<string>}
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.prototype.getUrnsList = function() {
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 1));
};
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.ConstructResponse.PropertyDependencies} returns this
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.prototype.setUrnsList = function(value) {
return jspb.Message.setField(this, 1, value || []);
};
/**
* @param {string} value
* @param {number=} opt_index
* @return {!proto.pulumirpc.ConstructResponse.PropertyDependencies} returns this
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.prototype.addUrns = function(value, opt_index) {
return jspb.Message.addToRepeatedField(this, 1, value, opt_index);
};
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.ConstructResponse.PropertyDependencies} returns this
*/
proto.pulumirpc.ConstructResponse.PropertyDependencies.prototype.clearUrnsList = function() {
return this.setUrnsList([]);
};
/**
* optional string urn = 1;
* @return {string}
*/
proto.pulumirpc.ConstructResponse.prototype.getUrn = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
/**
* @param {string} value
* @return {!proto.pulumirpc.ConstructResponse} returns this
*/
proto.pulumirpc.ConstructResponse.prototype.setUrn = function(value) {
return jspb.Message.setProto3StringField(this, 1, value);
};
/**
* optional google.protobuf.Struct state = 2;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.ConstructResponse.prototype.getState = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 2));
};
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.ConstructResponse} returns this
*/
proto.pulumirpc.ConstructResponse.prototype.setState = function(value) {
return jspb.Message.setWrapperField(this, 2, value);
};
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.ConstructResponse} returns this
*/
proto.pulumirpc.ConstructResponse.prototype.clearState = function() {
return this.setState(undefined);
};
/**
* Returns whether this field is set.
* @return {boolean}
*/
proto.pulumirpc.ConstructResponse.prototype.hasState = function() {
return jspb.Message.getField(this, 2) != null;
};
/**
* map<string, PropertyDependencies> stateDependencies = 3;
* @param {boolean=} opt_noLazyCreate Do not create the map if
* empty, instead returning `undefined`
* @return {!jspb.Map<string,!proto.pulumirpc.ConstructResponse.PropertyDependencies>}
*/
proto.pulumirpc.ConstructResponse.prototype.getStatedependenciesMap = function(opt_noLazyCreate) {
return /** @type {!jspb.Map<string,!proto.pulumirpc.ConstructResponse.PropertyDependencies>} */ (
jspb.Message.getMapField(this, 3, opt_noLazyCreate,
proto.pulumirpc.ConstructResponse.PropertyDependencies));
};
/**
* Clears values from the map. The map will be non-null.
* @return {!proto.pulumirpc.ConstructResponse} returns this
*/
proto.pulumirpc.ConstructResponse.prototype.clearStatedependenciesMap = function() {
this.getStatedependenciesMap().clear();
return this;};
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
/**
* List of repeated fields within this message type.
* @private {!Array<number>}
* @const
*/
proto.pulumirpc.ErrorResourceInitFailed.repeatedFields_ = [3];
if (jspb.Message.GENERATE_TO_OBJECT) {
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Creates an object representation of this proto.
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
* Field names that are reserved in JavaScript and will be renamed to pb_name.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* Optional fields that are not set will be set to undefined.
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
* To access a reserved field use, foo.pb_<name>, eg, foo.pb_default.
* For the list of reserved names please see:
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* net/proto2/compiler/js/internal/generator.cc#kKeyword.
* @param {boolean=} opt_includeInstance Deprecated. whether to include the
* JSPB instance for transitional soy proto support:
* http://goto/soy-param-migration
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
* @return {!Object}
*/
proto.pulumirpc.ErrorResourceInitFailed.prototype.toObject = function(opt_includeInstance) {
return proto.pulumirpc.ErrorResourceInitFailed.toObject(opt_includeInstance, this);
};
/**
* Static version of the {@see toObject} method.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {boolean|undefined} includeInstance Deprecated. Whether to include
* the JSPB instance for transitional soy proto support:
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
* http://goto/soy-param-migration
* @param {!proto.pulumirpc.ErrorResourceInitFailed} msg The msg instance to transform.
* @return {!Object}
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ErrorResourceInitFailed.toObject = function(includeInstance, msg) {
var f, obj = {
id: jspb.Message.getFieldWithDefault(msg, 1, ""),
properties: (f = msg.getProperties()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f),
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
reasonsList: (f = jspb.Message.getRepeatedField(msg, 3)) == null ? undefined : f,
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
inputs: (f = msg.getInputs()) && google_protobuf_struct_pb.Struct.toObject(includeInstance, f)
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
};
if (includeInstance) {
obj.$jspbMessageInstance = msg;
}
return obj;
};
}
/**
* Deserializes binary data (in protobuf wire format).
* @param {jspb.ByteSource} bytes The bytes to deserialize.
* @return {!proto.pulumirpc.ErrorResourceInitFailed}
*/
proto.pulumirpc.ErrorResourceInitFailed.deserializeBinary = function(bytes) {
var reader = new jspb.BinaryReader(bytes);
var msg = new proto.pulumirpc.ErrorResourceInitFailed;
return proto.pulumirpc.ErrorResourceInitFailed.deserializeBinaryFromReader(msg, reader);
};
/**
* Deserializes binary data (in protobuf wire format) from the
* given reader into the given message object.
* @param {!proto.pulumirpc.ErrorResourceInitFailed} msg The message object to deserialize into.
* @param {!jspb.BinaryReader} reader The BinaryReader to use.
* @return {!proto.pulumirpc.ErrorResourceInitFailed}
*/
proto.pulumirpc.ErrorResourceInitFailed.deserializeBinaryFromReader = function(msg, reader) {
while (reader.nextField()) {
if (reader.isEndGroup()) {
break;
}
var field = reader.getFieldNumber();
switch (field) {
case 1:
var value = /** @type {string} */ (reader.readString());
msg.setId(value);
break;
case 2:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setProperties(value);
break;
case 3:
var value = /** @type {string} */ (reader.readString());
msg.addReasons(value);
break;
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
case 4:
var value = new google_protobuf_struct_pb.Struct;
reader.readMessage(value,google_protobuf_struct_pb.Struct.deserializeBinaryFromReader);
msg.setInputs(value);
break;
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
default:
reader.skipField();
break;
}
}
return msg;
};
/**
* Serializes the message to binary data (in protobuf wire format).
* @return {!Uint8Array}
*/
proto.pulumirpc.ErrorResourceInitFailed.prototype.serializeBinary = function() {
var writer = new jspb.BinaryWriter();
proto.pulumirpc.ErrorResourceInitFailed.serializeBinaryToWriter(this, writer);
return writer.getResultBuffer();
};
/**
* Serializes the given message to binary data (in protobuf wire
* format), writing to the given BinaryWriter.
* @param {!proto.pulumirpc.ErrorResourceInitFailed} message
* @param {!jspb.BinaryWriter} writer
* @suppress {unusedLocalVariables} f is only used for nested messages
*/
proto.pulumirpc.ErrorResourceInitFailed.serializeBinaryToWriter = function(message, writer) {
var f = undefined;
f = message.getId();
if (f.length > 0) {
writer.writeString(
1,
f
);
}
f = message.getProperties();
if (f != null) {
writer.writeMessage(
2,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
f = message.getReasonsList();
if (f.length > 0) {
writer.writeRepeatedString(
3,
f
);
}
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
f = message.getInputs();
if (f != null) {
writer.writeMessage(
4,
f,
google_protobuf_struct_pb.Struct.serializeBinaryToWriter
);
}
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
};
/**
* optional string id = 1;
* @return {string}
*/
proto.pulumirpc.ErrorResourceInitFailed.prototype.getId = function() {
return /** @type {string} */ (jspb.Message.getFieldWithDefault(this, 1, ""));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {string} value
* @return {!proto.pulumirpc.ErrorResourceInitFailed} returns this
*/
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
proto.pulumirpc.ErrorResourceInitFailed.prototype.setId = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setProto3StringField(this, 1, value);
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
};
/**
* optional google.protobuf.Struct properties = 2;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.ErrorResourceInitFailed.prototype.getProperties = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 2));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.ErrorResourceInitFailed} returns this
*/
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
proto.pulumirpc.ErrorResourceInitFailed.prototype.setProperties = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 2, value);
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.ErrorResourceInitFailed} returns this
*/
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
proto.pulumirpc.ErrorResourceInitFailed.prototype.clearProperties = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setProperties(undefined);
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
*/
proto.pulumirpc.ErrorResourceInitFailed.prototype.hasProperties = function() {
return jspb.Message.getField(this, 2) != null;
};
/**
* repeated string reasons = 3;
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!Array<string>}
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
*/
proto.pulumirpc.ErrorResourceInitFailed.prototype.getReasonsList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return /** @type {!Array<string>} */ (jspb.Message.getRepeatedField(this, 3));
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {!Array<string>} value
* @return {!proto.pulumirpc.ErrorResourceInitFailed} returns this
*/
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
proto.pulumirpc.ErrorResourceInitFailed.prototype.setReasonsList = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setField(this, 3, value || []);
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
};
/**
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @param {string} value
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
* @param {number=} opt_index
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {!proto.pulumirpc.ErrorResourceInitFailed} returns this
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
*/
proto.pulumirpc.ErrorResourceInitFailed.prototype.addReasons = function(value, opt_index) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.addToRepeatedField(this, 3, value, opt_index);
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the list making it empty but non-null.
* @return {!proto.pulumirpc.ErrorResourceInitFailed} returns this
*/
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
proto.pulumirpc.ErrorResourceInitFailed.prototype.clearReasonsList = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setReasonsList([]);
Represent init errors in resource provider proto
2018-06-28 01:08:21 +02:00
};
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
/**
* optional google.protobuf.Struct inputs = 4;
* @return {?proto.google.protobuf.Struct}
*/
proto.pulumirpc.ErrorResourceInitFailed.prototype.getInputs = function() {
return /** @type{?proto.google.protobuf.Struct} */ (
jspb.Message.getWrapperField(this, google_protobuf_struct_pb.Struct, 4));
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* @param {?proto.google.protobuf.Struct|undefined} value
* @return {!proto.pulumirpc.ErrorResourceInitFailed} returns this
*/
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
proto.pulumirpc.ErrorResourceInitFailed.prototype.setInputs = function(value) {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return jspb.Message.setWrapperField(this, 4, value);
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
};
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
/**
* Clears the message field making it undefined.
* @return {!proto.pulumirpc.ErrorResourceInitFailed} returns this
*/
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
proto.pulumirpc.ErrorResourceInitFailed.prototype.clearInputs = function() {
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
return this.setInputs(undefined);
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
};
/**
* Returns whether this field is set.
Regenerate protocol buffers code
2020-02-28 12:53:47 +01:00
* @return {boolean}
Update the provider RPC interface (#2512) These changes add two new methods to the provider interface and extend the results of three others. The new methods are `CheckConfig` and `DiffConfig`, which fill out the set of methods required for a complete implementation of the first-class provider design. Though these methods are optional for backwards compatibility, they should be implemented by all future providers for the best possible user experience. The adjusted result types are `DiffResponse`, `ReadResponse`, and `ErrorResourceInitFailed`. The first has been updated to include a list of the properties that changed (if any). The latter two now include an estimated set of inputs for the resource as well as the resource's state. Together, these three changes enable the engine to determine the set of inputs that should be specified by a user in order to match those that describe the resource's current state. This contributes to #2453, #1662, #1635, and #1718.
2019-03-05 19:49:24 +01:00
*/
proto.pulumirpc.ErrorResourceInitFailed.prototype.hasInputs = function() {
return jspb.Message.getField(this, 4) != null;
};
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
goog.object.extend(exports, proto.pulumirpc);
Reference in a new issue Copy permalink