This commit adds the definitions of provider protocol 5.8 and 6.8 to our
archive of the historical protocol versions and then adopts each as the
current version of each of its major series.
These MPL-licensed schema definitions are from the plugin protocol server
implementation in this repository, copyright HashiCorp:
https://github.com/hashicorp/terraform-plugin-go
The only modifications made are to change the "option go_package" directive
to match where the stubs need to be generated for OpenTofu, and to claim
copyright for that change and thus make the copyright header consistent
with what our pre-commit rules require.
The regeneration of the Go API stubs for the two major protocol versions
introduces some new fields and messages that OpenTofu does not yet support
but will happily ignore. Future work might make some use of these new
additions, but that's out of scope of this change that is intended only
to synchronize our protocol definition with what new plugin server releases
are likely to be linked against.
Compared to the previous minor releases of each series this only introduces
new fields to existing message types and does not define any new RPC
functions, so we don't need any changes to the "grpcwrap" and "mock_proto"
packages in this case.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This commit adds the definitions of provider protocol 5.6, 5.7, 6.6, and
6.7 to our archive of the historical protocol versions and then adopts
5.7 as the current version of major version 5 and 6.7 as the current
version of major version 6.
These MPL-licensed schema definitions are from the plugin protocol server
implementation in this repository, copyright HashiCorp:
https://github.com/hashicorp/terraform-plugin-go
The only modifications made are to change the "option go_package" directive
to match where the stubs need to be generated for OpenTofu, and to claim
copyright for that change and thus make the copyright header consistent
with what our pre-commit rules require.
The regeneration of the Go API stubs for the two major protocol versions
introduces some new fields and messages that OpenTofu does not yet support
but will happily ignore. Future work might make some use of these new
additions, but that's out of scope of this change that is intended only
to synchronize our protocol definition with what new plugin server releases
are likely to be linked against.
This commit continues the existing precedent of having the stubs for the
newly-added interface methods in package grpcwrap being just a panicking
stub, which is how they will remain until a future project begins using
those methods in a way which requires them to be implemented, since
implementing the wrappers would require a deeper understanding of the
desired behavior of those methods.
It appears that we previously accepted a pull request to correct a typo
that originated in the older versions of the upstream protocol definitions,
but I have intentionally not forward-ported that here because it seems
clearer to keep these definitions as close as possible to their source
of truth from upstream, given that our current intention is to follow the
protocol as documented and not to change it.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
* Rename module name from "github.com/hashicorp/terraform" to "github.com/placeholderplaceholderplaceholder/opentf".
Signed-off-by: Jakub Martin <kubam@spacelift.io>
* Gofmt.
Signed-off-by: Jakub Martin <kubam@spacelift.io>
* Regenerate protobuf.
Signed-off-by: Jakub Martin <kubam@spacelift.io>
* Fix comments.
Signed-off-by: Jakub Martin <kubam@spacelift.io>
* Undo issue and pull request link changes.
Signed-off-by: Jakub Martin <kubam@spacelift.io>
* Undo comment changes.
Signed-off-by: Jakub Martin <kubam@spacelift.io>
* Fix comment.
Signed-off-by: Jakub Martin <kubam@spacelift.io>
* Undo some link changes.
Signed-off-by: Jakub Martin <kubam@spacelift.io>
* make generate && make protobuf
Signed-off-by: Jakub Martin <kubam@spacelift.io>
---------
Signed-off-by: Jakub Martin <kubam@spacelift.io>
This is actually a description of the "cty" library's encoding of refined
values, but from the perspective of the plugin protocol it's an
implementation detail that Terraform Core outsources that to a third-party
library, and current server-side implementations of the protocol use an
independent implementation of this format which will need to be compatible
with what cty does.
Reference: 21bb677db7/internal/plans/objchange/objchange.go (L289-L292)
Previously, the resource lifecycle documentation for Proposed New State only mentioned special behavior for Optional and Computed attributes. This minor documentation update mentions that Terraform also imposes special behavior on Computed-only attributes (preserving any Prior State value).
I missed this on my first attempt to write this document. Consequently
we're currently depending on a version of HCL which uses Unicode 9, and
that's significantly lagging behind everything else which is currently on
Unicode 13.
My goal of adding these docs then is to remind us to update HCL to Unicode
15 once we're updating everything else to Unicode 15 with the Go 1.20
release, assuming that the Go team completes that Unicode upgrade as
currently planned.
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
```
There are small typos in:
- docs/planning-behaviors.md
- docs/resource-instance-change-lifecycle.md
- website/README.md
Fixes:
- Should read `exhaustive` rather than `exhastive`.
- Should read `representation` rather than `repesentation`.
- Should read `preferably` rather than `preferrably`.
- Should read `absence` rather than `absense`.
The previous version of this document was produced in haste in order to
support the development of the new provider framework, and so it focused
only on the most important details and left some of the operations totally
unmentioned.
This new version aims to capture the full set of managed-resource-related
provider operations, documenting when Terraform Core will call them and
what the provider ought to do in order to meet Terraform Core's
expectations for a valid response.
This new version does still assume a certain amount of knowledge on the
part of the reader about broadly what Terraform does from a user
perspective and what role providers play in that process. Perhaps a future
revision will include some additional background context as well, but
this is a snapshot of what I had time to do today between other work and
so for now I focused on presenting the remaining operations in a similar
amount of detail to what was here before.
For a while now we've had information equivalent to this in various
internal documents that we've referred to when designing features such as
config-driven refactoring, the "replace" planning option, and so forth.
However, so far we've not put that information in any sort of durable
public place that we can easily find and refer to when having design
discussions on GitHub and similar.
This is therefore an attempt to capture a summary of the three main design
patterns we've identified for planning-related behaviors, with a few
motivating examples of each one, in the hope that this will be a good
reference and some helpful inspiration for future design work.
It's intentionally not totally comprehensive of all planning behaviors
both because that would duplicate the end-user-oriented documentation and
because it would be burdensome to keep updating this document each time we
add anything new which might fit into these categories. However, we might
add a later feature to this document if it illustrates a new take or
different perspective on one of these patterns.
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
```
As explained in the changes: The 'enhanced' backend terminology, which
only truly pertains to the 'remote' backend with a single API (Terraform
Cloud/Enterprise's), has been found to be a confusing vestige which need
only be explained in the context of the 'remote' backend.
These changes reorient the explanation(s) of backends to pertain more
directly to their primary purpose, which is storage of state snapshots
(and not implementing operations).
That Terraform operations are still _implemented_ by the literal
`Backend` and `Enhanced` interfaces is inconsequential a user of
Terraform, an internal detail.
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.
