terraform

Commit Graph

Author	SHA1	Message	Date
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
Masayuki Morita	bdf683802d	docs: Fix typo in docs/plugin-protocol/releasing-new-version.md	4 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.	4 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.	4 years ago
Paddy	64a95fc29f	Add docs on how to release a new major protocol version. (#29552 ) Releasing a new major protocol version requires coordination between a few different projects and codebases, and it's easy to forget a step. This commit introduces a doc to keep track of these steps, making it less likely one will be omitted or forgotten.	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
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
Martin Atkins	6b4ed241d3	docs: Provider protocol wire format for values Although we have in this same directory the protocol buffers schemas for the static parts of the provider wire protocol, many of the protocol messages include DynamicValue messages that are presented in a nested dynamic serialization format. That format was previously not documented, and was thus defined only by the implementation. Terraform happens to use a third-party library to implement parts of this encoding, which means that the rules were even harder to track down from reading the code. Regardless of how Terraform happens to implement its serialization and deserialization of DynamicValue, it's the wire format that is contractual and so this document is an implementation-agnostic description of the mapping rules for serializing any Terraform Language value by reference to a provider-defined schema. All future changes to the rules described in here must be backward compatible until protocol major version 6, which is not currently planned.	6 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
Martin Atkins	e1af10b554	docs: README for the plugin-protocol directory This is an initial partial description of the plugin protocol focused mainly on explaining the purpose of the .proto files. In subsequent updates we will also document the negotiation protocol, etc. For this first pass the goal was just to publish some information that was already available in an internal design document so that it's visible to SDK implementers. It is focused on the .proto versioning strategy because that was the main topic of the internal design documentation this was based on.	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

15 Commits (235a8b7fcc00c6d60487a68221b1cc342d8918c3)