26 Commits (2cc94b4e89ccd47475c2b894e7cb9bd758ae73fc)

Author	SHA1	Message	Date
CJ Horton	813369f317	stick with go generate check instead	3 years ago
Brian Flad	7094517089	Add GetMetadata RPC to provider protocol (#33739) ... Reference: https://github.com/hashicorp/terraform/pull/33486 This is a followup to the new provider server capability to make the `GetProviderSchema` RPC optional. While this server capability would perform its intended function when directly talking to a single provider server SDK implementation, provider servers using terraform-plugin-mux need a methodology for the mux server to determine the available resource types of each underlying provider server to properly route resource-specific RPCs. Since the only methodology available to the mux server would be calling the `GetProviderSchema` RPC to each of underlying provider servers, any memory optimization of core caching would be lost. The choice of adding a new RPC instead of adjusting the existing `GetProviderSchema` RPC with additional request information, such as "only list the type names and not the schema information in the response", is two-fold: - Prevents the introduction of conditional logic for the existing RPC. - Clearly delineates the purpose of the RPC and can be documented easier. The choice of adding this to the existing provider service is two-fold: - Implementing a separate protocol and/or service only on the provider side of the protocol would be a novel design change. This small of a change does not warrant the potential research and testing effort that would be associated with that implementation. - While the core implementation will not use the new RPC immediately, there is no reason why it should be restricted from doing so in the future if a valid use case surfaces. Other ecosystem tools, beyond terraform-plugin-mux, can also potentially benefit from the lightweight RPC now. This is changing the 5.4 and 6.4 protocol versions following the guidance of this comment in the definition files, since it directly relates to the prior intention of the new minor versions: ```protobuf // Note that only the proto files included in a release tag of Terraform are // official protocol releases. Proto files taken from other commits may include // incomplete changes or features that did not make it into a final release. // In all reasonable cases, plugin developers should take the proto file from // the tag of the most recent release of Terraform, and not from the main // branch or any other development branch. ``` As with any Protocol Buffers definition update, protocol compatibility is guaranteed within a major version, however generated protocol source code compatibility is not guaranteed. In this case, implementing the new RPC method in protocol wrapper types and the moving of the `ServerCapabilities` message to the top namespace are considered acceptable changes.	3 years ago
CJ Horton	c09daa7dc7	update license for provider plugin protocol files	3 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
James Bardin	f5d94b35a0	Merge pull request #33486 from hashicorp/jbardin/schema-cache-proto ... enable schema caching and add `get_provider_schema_optional` server capability	3 years ago
Martin Atkins	a7807dac16	main: Optionally configure an OpenTelemetry OTLP exporter ... Terraform CLI is sometimes used as part of a larger distributed system, in which case it would be helpful to be able to gather telemetry from it as part of the larger request it's being run in response to. We'll now support optionally enabling an OTLP exporter by setting the environment variable OTEL_TRACES_EXPORTER=otlp (a standard OpenTelemetry convention). As of this commit there isn't actually anything emitting traces to the specified collector, but we'll gradually add tracing instrumentation to parts of Terraform CLI and Core in later commits.	3 years ago
James Bardin	fb35d7fd89	add get_provider_schema_optional server capability	3 years ago
Alisdair McDiarmid	b5658a46a2	Rebuild protobuf	3 years ago
Sarah French	6fd3a8cdf4	go get cloud.google.com/go/storage@v1.28.0 (#32203) ... * go get cloud.google.com/go/storage@v1.28.0 * go mod tidy * Run `make generate` & `make protobuf` using go1.19.3	3 years ago
Brian Flad	8c93420270	docs/plugin-protocol: Add notes about missing configuration in ReadResource and UpgradeResourceState request messages (#31998) ... This opts to inline document these intentional design decisions in the protocol definition as a catch-all for it not being documented elsewhere. Protocol Buffers files updated via: ```shell make protobuf ```	3 years ago
Martin Atkins	783a07d9e8	build: Use Go 1.19 ... Go 1.19's "fmt" has some awareness of the new doc comment formatting conventions and adjusts the presentation of the source comments to make it clearer how godoc would interpret them. Therefore this commit includes various updates made by "go fmt" to acheve that. In line with our usual convention that we make stylistic/grammar/spelling tweaks typically only when we're "in the area" changing something else anyway, I also took this opportunity to review most of the comments that this updated to see if there were any other opportunities to improve them.	4 years ago
James Bardin	26c569e384	s/Capabilities/ServerCapabilities/	4 years ago
James Bardin	b9f1a5ac57	add Schema Capabilities to protocol	4 years ago
Martin Atkins	2e6b6e9a6b	go.mod: go get google.golang.org/protobuf@v1.27.1	4 years ago
Martin Atkins	ce96d82de0	build: Centralize our protobuf compilation steps ... We have a few different .proto files in this repository that all need to get recompiled into .pb.go files each time we change them, but we were previously handling that with some scripts that just assumed that protoc and the relevant plugins were already installed on the system somewhere, at the right versions. In practice we've been constantly flopping between different versions of these tools due to folks having different versions installed in their development environments. In particular, the state of the .pb.go files in the prior commit wasn't reproducible by any single version of the tools because they've all slightly diverged from one another. In the interests of being more consistent here and avoiding accidental inconsistencies, we'll now centralize the protocol buffer compile steps all into a single tool that knows how to fetch and install the expected versions of the various tools we need and then run those tools with the right options to get a stable result. If we want to upgrade to either a newer protoc or a newer protoc-gen-go in future then we'll do that in a central location and update all of the .pb.go files at the same time, so that we're always consistently tracking the same version of protocol buffers everywhere. While doing this I attempted to keep as close as possible to the toolchain we'd most recently used, but since they were not consistent with each other they've now all changed which version numbers they record at minimum, and the planproto stub in particular now also has a slightly different descriptor serialization but is otherwise offering the same API.	5 years ago
Kristin Laemmert	106bcd3bf0	update to match new default branch name (#27909)	5 years ago
James Bardin	ccf19fbf5e	regenerate plugin proto with correct tooling ... The proto file is structurally unchanged, though it now requires a go import path option.	5 years ago
Paddy	e6592dc710	Add support for provider metadata to modules. (#22583) ... Implement a new provider_meta block in the terraform block of modules, allowing provider-keyed metadata to be communicated from HCL to provider binaries. Bundled in this change for minimal protocol version bumping is the addition of markdown support for attribute descriptions and the ability to indicate when an attribute is deprecated, so this information can be shown in the schema dump. Co-authored-by: Paul Tyng <paul@paultyng.net>	6 years ago
Radek Simko	3d94baecf6	Regenerate protobuf files under latest versions ... Used protobuf 3.9.1 with protoc-gen-go 1.3.2	7 years ago
James Bardin	fa1f9be539	add tfplugin proto docs files ... Add versioned tfplugin proto files to the docs directory, for easier reference. The latest version starts as a symlink to the current file used for generated the tfplugin package in ./internal/tfplugin5. When changing the protocol version, the old file must be copied to ./docs/plugin-protocol/, and a new symlink created for the latest version.	7 years ago
James Bardin	863bfdce06	set proto version 5.1 ... With the addition of the private field to ReadResource, we need to bump the proto version to 5.1.	7 years ago
James Bardin	e2b2f1bbbc	add Private fields to ReadResource ... Private data was previously created during Plan, and sent back to the provider during Apply. This data also needs to be persisteded accross Read calls, but rather than rely on core for that we can send the data to the provider during Read to allow for more flexibilty.	7 years ago
Martin Atkins	88e76fa9ef	configs/configschema: Introduce the NestingGroup mode for blocks ... In study of existing providers we've found a pattern we werent previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block. The existing NestingSingle was not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected. NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured. The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway. We're adding this now so that we can introduce the feature in a future SDK without causing a breaking change to the protocol, since the set of possible block nesting modes is not extensible.	7 years ago
Martin Atkins	31299e688d	core: Allow legacy SDK to opt out of plan-time safety checks ... Due to the inprecision of our shimming from the legacy SDK type system to the new Terraform Core type system, the legacy SDK produces a number of inconsistencies that produce only minor quirky behavior or broken edge-cases. To retain compatibility with those existing weird behaviors, the legacy SDK opts out of our safety checks. The intent here is to allow existing providers to continue to do their previous unsafe behaviors for now, accepting that this will allow certain quirky bugs from previous releases to persist, and then gradually migrate away from the legacy SDK and remove this opt-out on a per-resource basis over time. As with the apply-time safety check opt-out, this is reserved only for the legacy SDK and must not be used in any new SDK implementations. We still include any inconsistencies as warnings in the logs as an aid to anyone debugging weird behavior, so that they can see situations where blame may be misplaced in the user-visible error messages.	7 years ago
Martin Atkins	1530fe52f7	core: Legacy SDK providers opt out of our new apply result check ... The shim layer for the legacy SDK type system is not precise enough to guarantee it will produce identical results between plan and apply. In particular, values that are null during plan will often become zero-valued during apply. To avoid breaking those existing providers while still allowing us to introduce this check in the future, we'll introduce a rather-hacky new flag that allows the legacy SDK to signal that it is the legacy SDK and thus disable the check. Once we start phasing out the legacy SDK in favor of one that natively understands our new type system, we can stop setting this flag and thus get the additional safety of this check without breaking any previously-released providers. No other SDK is permitted to set this flag, and we will remove it if we ever introduce protocol version 6 in future, assuming that any provider supporting that protocol will always produce consistent results.	7 years ago
Martin Atkins	4fe9632f09	plugin: Establish our current plugin protocol as version 5 ... The main significant change here is that the package name for the proto definition is "tfplugin5", which is important because this name is part of the wire protocol for references to types defined in our package. Along with that, we also move the generated package into "internal" to make it explicit that importing the generated Go package from elsewhere is not the right approach for externally-implemented SDKs, which should instead vendor the proto definition they are using and generate their own stubs to ensure that the wire protocol is the only hard dependency between Terraform Core and plugins. After this is merged, any provider binaries built against our helper/schema package will need to be rebuilt so that they use the new "tfplugin5" package name instead of "proto". In a future commit we will include more elaborate and organized documentation on how an external codebase might make use of our RPC interface definition to implement an SDK, but the primary concern here is to ensure we have the right wire package name before release.	7 years ago