Open bflad opened 2 years ago
For completeness: another potential option here would be to use the tfsdklog.SubsystemWith()
approach, but save the Terraform CLI version in the provider server and use that saved value (if found) on the other subsequent RPCs, since it is generally expected that a provider server would only ever interact with a single client over its lifetime. However, one anti-example of that type of approach would be when using a provider server in reattach mode, where it is possible for developers to swap the Terraform CLI being used while keeping the same server running.
terraform-plugin-go version
Use cases
Provider developers and SDK maintainers often need to know the associated Terraform CLI version when triaging issues. Certain classes of issues are resolved via Terraform CLI upgrades. Unless the Terraform CLI portion of logging is enabled, which does include the Terraform CLI version as a log entry, there is currently no SDK-side logging of the version.
Attempted solutions
Asking issue reporters in issue templates. Looking for version information from the Terraform CLI log entries, if they were enabled.
Proposal
The
ConfigureProvider
RPC request contains theTerraformVersion
field, which should be appropriately populated by Terraform CLI. The RPC handlers could either:logging.ProtocolDebug(ctx, "Detected Terraform CLI version: "+req.TerraformVersion)
tfsdklog.SubsystemWith(ctx, SubsystemProto, KeyTfVersion, version)
If more or all of the RPCs contained the version, the latter would generally be preferred so the information propagates out all associated log entries, however the single entry may be less confusing for now.
References