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.
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>
Previously we were using the experimental HCL 2 repository, but now we'll
shift over to the v2 import path within the main HCL repository as part of
actually releasing HCL 2.0 as stable.
This is a mechanical search/replace to the new import paths. It also
switches to the v2.0.0 release of HCL, which includes some new code that
Terraform didn't previously have but should not change any behavior that
matters for Terraform's purposes.
For the moment the experimental HCL2 repository is still an indirect
dependency via terraform-config-inspect, so it remains in our go.sum and
vendor directories for the moment. Because terraform-config-inspect uses
a much smaller subset of the HCL2 functionality, this does still manage
to prune the vendor directory a little. A subsequent release of
terraform-config-inspect should allow us to completely remove that old
repository in a future commit.
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.
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.
This doc was originally written in the middle of Terraform v0.12
development while some refactoring was already in progress. Here we update
those parts to refer to where the relevant functionality finally landed,
and also update some things that we did not anticipate changing at the
time but ended up having to be changed during the v0.12 development
anyway.
For a while now we've been gathering some codebase-level docs that felt
out-of-place on the main Terraform website (since they are about the
implementation, not usage) but we had no existing suitable place to put
them.
In order to make this information more available (and, hopefully, more
likely to stay up-to-date as we change things), here we'll establish the
"docs" directory as a place to keep documentation aimed at those who are
working on code changes to the Terraform Core codebase.
User-oriented docs should never appear in this directory. The Terraform
website is always the better place for those. The set of docs here is
rudimentary to start and we'll see if it makes sense to expand and
reorganize it over time based on the experience with having these initial
docs available.
James Bardin