terraform

Commit Graph

Author	SHA1	Message	Date
Liam Cervante	7d143388f3	Add support for the cross resource type move operation in the proto schema (#34480 ) * Update proto schema and provider interfaces with support for moved across resource type RPCs * address comments * remove unused functions * remove support for flatmap format	2 years ago
hc-github-team-es-release-engineering	6114ec4390	Merge pull request #34367 from hashicorp/RELPLAT-955-EOY-license-updates [DO NOT MERGE UNTIL EOY] EOY license updates	2 years ago
James Bardin	c439b72599	proto: add provider-defined functions	2 years ago
hc-github-team-es-release-engineering	a90ba0bfe4	update year in license files	2 years ago
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 ```	4 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
Brian Flad	a477d10bd1	Introduce Terraform Plugin Protocol 6.2 with legacy_type_system fields from Protocol 5 (#30375 ) Reference: https://github.com/hashicorp/terraform/issues/30373 This change forward ports the `legacy_type_system` boolean fields in the `ApplyResourceChange.Response` and `PlanResourceChange.Response` messages that existed in protocol version 5, so that existing terraform-plugin-sdk/v2 providers can be muxed with protocol version 6 providers (e.g. terraform-plugin-framework) while also taking advantage of the newer protocol features. This functionality should not be used by any providers or SDKs except those built with terraform-plugin-sdk. Updated via: ```shell cp docs/plugin-protocol/tfplugin6.1.proto docs/plugin-protocol/tfplugin6.2.proto # Copy legacy_type_system fields from tfplugin5.2.proto into ApplyResourceChange.Response and PlanResourceChange rm internal/tfplugin6/tfplugin6.proto ln -s ../../docs/plugin-protocol/tfplugin6.2.proto internal/tfplugin6/tfplugin6.proto go run tools/protobuf-compile/protobuf-compile.go `pwd` # Updates to internal/plugin6/grpc_provider.go ```	4 years ago
James Bardin	9b62dd6901	Merge pull request #29648 from hashicorp/jbardin/tfproto6.1 tfproto version 6.1	5 years ago
Martin Atkins	2e6b6e9a6b	go.mod: go get google.golang.org/protobuf@v1.27.1	5 years ago
James Bardin	fe671206cc	Add detail about the protocol deprecation Make sure it's clear that the deprecated fields serve no purpose, and should be ignored.	5 years ago
James Bardin	24a2bd6301	tfproto version 6.1 Minor version increase to deprecate min_items and max_items in nested types. Nested types have MinItems and MaxItems fields that were inherited from the block implementation, but were never validated by Terraform, and are not supported by the HCL decoder validations. Mark these fields as deprecated, indicating that the SDK should handle the required validation.	5 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
Kristin Laemmert	ff05362d51	providers.Interface: rename ValidateDataSourceConfig to ValidateDataResourceConfig (#27874 ) * providers.Interface: rename ValidateDataSourceConfig to ValidateDataResourceConfig This PR came about after renaming ValidateResourceTypeConfig to ValidateResourceConfig: I now understand that we'd called it the former instead of the latter to indicate that the function wasn't necessarily operating on a resource that actually exists. A possibly-more-accurate renaming of both functions might then be ValidateManagedResourceConfig and ValidateDataResourceConfig. The next commit will update the protocol (v6 only) as well; these are in separate commits for reviewers and will get squashed together before merging. * extend renaming to protov6	5 years ago
Kristin Laemmert	f3a057eb35	plugin-protocol v6 This is the first commit for plugin protocol v6. This is currently unused (dead) code; future commits will add the necessary conversion packages, extend configschema, and modify the providers.Interface. The new plugin protocol includes the following changes: - A new field has been added to Attribute: NestedType. This will be the key new feature in plugin protocol v6 - Several massages were renamed for consistency with the verb-noun pattern seen in _most_ messages. - The prepared_config has been removed from PrepareProviderConfig (renamed ValidateProviderConfig), as it has never been used. - The provisioner service has been removed entirely. This has no impact on built-in provisioners. 3rd party provisioners are not supported by the SDK and are not included in this protocol at all.	5 years ago

26 Commits (1298fcd41259c2cf66306cce2453efd2c19f445d)