I'm unable to locate this documentation in the GH repos, although I'm sure it's here somewhere.

I went looking for docs on writing a custom TF provider, and found https://developer.hashicorp.com/terraform/tutorials/providers. In the left side gutter under "Integrations" are two nearly identical looking options for custom providers: "Custom Framework Providers" and "Custom SDK Providers". The description of both only varies in the name/title. It's entirely unclear why both are there and which to use. Screenshots attached for reference.

It's not until I went hunting for the answer that I found another page under "plugins" that explains the difference. It says

SDKv2 is the prior SDK that many existing providers use. It is maintained for Terraform versions 1.x and earlier, but we have stopped most feature development so we can focus on improving the framework.

To alleviate confusion and help developers move to use (or start with) the Plugin Framework, this description/explanation/suggestion above the tutorial TOC should include some form of the above statement making it clear that the SDK is not preferred.

A customer is not satisfied that within the current iteration of our documentation regarding Execution Modes there's not an explicit statement about team permissions not getting gracefully regulated/upheld when using the local execution mode, and I'm struggling to figure out an eloquent way to do this.

For example:

You are running terraform apply against a workspace in your TFC org, where the team your token is associated to does not have permissions to upload state files, or run applies

If remote execution is selected, you'd get this message when you attempted to execute terraform apply:

PS C:\Users\zisom\Documents\exxon> terraform apply
╷
│ Error: Insufficient rights to apply changes
│
│ The provided credentials have insufficient rights to apply changes. In order to apply changes at least write permissions on the workspace are required.
╵
PS C:\Users\zisom\Documents\exxon> 

If local execution is selected, the apply phase would execute, and when the apply was finished and terraform attempts to upload the new state file you'd see this message:

null_resource.delay (local-exec):                                  [01]: 172.17.176.1
null_resource.delay (local-exec):                                  [02]: fe80::8167:3d5c:2f54:7577
null_resource.delay (local-exec): Hyper-V Requirements:      A hypervisor has been detected. Features required for Hyper-V will not be displayed.
null_resource.delay: Creation complete after 2s [id=2000534191006407307]
╷
│ Error: Failed to save state
│
│ Error saving state: Error uploading state: resource not found
╵
╷
│ Error: Failed to persist state to backend
│
│ The error shown above has prevented Terraform from writing the updated state to the configured backend. To allow for recovery, the state has been written to the 
│ file "errored.tfstate" in the current working directory.
│
│ Running "terraform apply" again at this point will create a forked state, making it harder to recover.
│
│ To retry writing this state, use the following command:
│     terraform state push errored.tfstate
│
╵

Through local execution, team permissions do not regulate the local execution of the binary. A person only would run into a situation with their permissions when there was an api call from the local binary that is not permitted, like in this case, uploading a state file. How can this be expressed within our documentation?

It is not clear to me which IPs is Terraform Cloud using to manage resources when talking to the provider.

I checked the documentation: https://github.com/hashicorp/terraform-docs-common/blob/main/website/docs/cloud-docs/api-docs/ip-ranges.mdx

I created an application for the OVH provider and I need the list of IPs to authorize.

Use-cases

The current website documentation for Plugin Development discusses the Terraform Plugin Protocol but does not go into detail regarding the relationship between the RPCs that are issued by Terraform core during execution of a Terraform command and the Terraform plugin framework functions that are called as a consequence.

Proposal

In order to provide further clarification for provider developers and practitioners about the relationship and sequencing of RPCs and the functions that are called in the Terraform plugin framework it is proposed that Terraform Plugin Protocol be split into a separate page which adds this detail.

The Terraform plugin framework documentation will be updated to reference the relevant RPC within the new Terraform Plugin Protocol page.

References

• Document Relationships Between Terraform Commands, Protocol RPCs, and Framework Functionality

Hi team, I was releasing a terraform provider and I met the following errors.

The doc says

There are 1 or more zip files containing the built provider binary for a single architecture.
The binary name is terraform-provider-{NAME}_v{VERSION}.
The archive name is terraform-provider-{NAME}_{VERSION}_{OS}_{ARCH}.zip.

But when I was doing this, and terraform init throws an error

│ Error: Failed to install provider
│
│ Error while installing azure/azapi v0.1.0: unsuccessful request to
│ https://github.com/Azure/terraform-provider-azapi/releases/download/v0.1.0/terraform-provider-azapi_v0.1.0_windows_amd64.zip: 404 Not Found
╵

Please notice the difference is v before version v0.1.0. After I renamed the archives by adding v before version, it works.

I think this is kind of strange that these files are not following the same pattern, zip files/binary files have v before version, but checksum file and signature file don't.

https://www.terraform.io/registry/providers/publishing?_ga=2.204875920.1848645224.1649644205-1459696673.1614833669#manually-preparing-a-release

The "Edit this page on GitHub" hyperlink on the bottom of every Enterprise doc page is invalid, as it's still referencing (presumably) an old repo. After reading the README of this repo, it does mention the repo for /enterprise is an internal repository, so I can't say for certain if the currently linked repo is deprecated or not as I do not have the needed access to verify.

I'd suggest that if the public is unable to access the docs and modify it themselves via the usual method of submitting a PR, then can we please have some other kind of link so that we can put in a request for changes to be made elsewhere?

Example:
https://developer.hashicorp.com/terraform/enterprise/api-docs/workspaces#show-workspace

https://github.com/hashicorp/terraform-docs-common/blob/main/website/docs/cloud-docs/workspaces/settings/run-tasks.mdx should be updated to reflect the new stages available for run tasks

specifically

Run tasks perform actions between the plan and apply stages of a Terraform run.

is no longer true

The Team Token API documentation page does not show that you can call GET /teams/:team_id/authentication-token to see if an team has an existing API token, and, if the token does exist, when it was created and by whom.

This appears to be the call app.terraform.io calls when you go to https://app.terraform.io/app/:organization/settings/team/:team_id to display the "Team API Token" section.

https://github.com/hashicorp/terraform-docs-common/blob/main/website/docs/cloud-docs/api-docs/run.mdx

update the table of run states, to comprehensively and consistently call out those states that are considered final states

Hi,

I would like to use ECC GPG signing key because it is safer than RSA, DSA keys.
But, currently, Terraform Registry API doesn't support it.

Do you have a plan to support it?

ref

• https://www.terraform.io/registry/providers/publishing#preparing-and-adding-a-signing-key
• https://github.com/hashicorp/terraform-docs-common/blob/main/website/docs/registry/providers/publishing.mdx

when we can expect google_dataproc_cluster, BigQurey and other DATA workloads Support for GCP resources in Terraform Cloud Cost Estimation ?? or is there any possibility for customization for the GCP resources ?

Hi!

I would love to introduce a minor fix specified in in #659 it fixes a table in the documentation.

Please do reach out if I can help facilitate this PR to be merged.

Thank you

The documentation at https://developer.hashicorp.com/terraform/docs lacks proper navigation.
There are atleast 3 different ways to navigate the documentation, one from top nav, one from side bar and one from within the page (if this page is an index page)

As a first time user to terraform, I'd like to be able to properly read through documentation in a sequential manner ex: Prev, Next at the bottom of each page. The current documentation lacks this and I keep navigating pages repetitively selecting from top nav and side nav loosing my way constantly and get confused and lose interest

Terraform Cloud org settings have session timeout settings that do not appear to be documented in any of the terraform cloud docs.

Located in TFC org settings, Authentication (Security subhead)

User Sessions
You can make changes here that will affect the sessions of all users in this organization.

These should be documented.

Web pages within the Terraform registry site no longer have unique / relevant page titles or meta descriptions. All pages have the title "Terraform Registry"

This is resulting in pages no longer being searchable in Google Search.

An example of this would be: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/service_fabric_cluster

If you google the URL or resource name it does not appear in search.

Either here or in the docs, we should include a simple example using bash or something instead of goreleaser for environments where people can't introduce a new tool.

The documentation in this link "https://www.terraform.io/registry/modules/publish" says that there is a manual option to sync latest tags from Github repository , but not able to find the manage module dropdown in the UI.

If your version doesn't appear properly, you may force a sync with GitHub by viewing your module on the registry and clicking "Resync Module" under the "Manage Module" dropdown.

The workspace creation endpoint has an undocumented 'resource-count' attribute.
This attribute does not appear in the list of attributes, but is included in each of the example payloads.

I can't see how creating a new workspace could/should contain this attribute or how the value would be calculated to pass to it, since at the point of creation, there wouldn't be any resources (at least 'resources' from a Terraform concept - but maybe this is a different type of resource?)

Any advice would be much appreciated - since it's included in both of the examples, I assume it's not a mistake, but happy to submit a PR to remove if it's incorrectly there :)

Many thanks

The tfe_logo.png referenced in https://github.com/hashicorp/terraform-docs-common/blob/main/website/docs/cloud-docs/vcs/github.mdx?plain=1#L71 seems to be missing

Update the descriptions for objects in Terraform Cloud

Description

The documentation around Drift Detection includes this statement:

Configuration drift occurs when changes are made outside Terrafoto's regular process, 
leading to inconsistencies between the remote objects and your configured infrastructure.

Assuming this is supposed to be Terraform's than Terrafoto's.

In the variable sets documentation (https://github.com/hashicorp/terraform-website/blob/master/content/cloud-docs/api-docs/variable-sets.mdx) the table that specifies the required attributes doesn't quite line up with the payload below (the payload is correct).

The table lists the following fields:

data.name
data.description.
data.global

They should actually be:

data.attributes.name
data.attributes.description.
data.attributes.global

Apologies if this is the wrong place to raise this (directions to the right place would be appreciated in this case).

Some time ago, the filter feature of the provider documentation started including results which are seemingly unrelated to the value entered in the filter field.

For example, the below screenshot shows completely unrelated resources showing up when attempting to filter on "aws_instance":

Description

The Terraform CLI internals documentation has a page describing Provider Metadata, a lesser-known feature where provider developers who also happen to be module developers can support module-level "provider" configuration.

Since this functionality was introduced, Terraform CLI has it included with 1.0 compatibility promises, so it is not intended to go anywhere for awhile. It is no longer considered an "experimental" feature. Both current major protocol versions support the data and its usable with both terraform-plugin-sdk/v2 and terraform-plugin-framework.

Given that this functionality requires provider implementation and that additional providers may benefit from it, this documentation should likely be promoted to the plugin/ section of the website where each development framework can document the implementation specifics.

as per the changes in 1.4 (release notes) it seems localterraform.com is no longer TFE only and the documentation should be updated to reflect this.

The text above the field overview says

By supplying the necessary attributes under a vcs-repository object, you can create a workspace that is configured against a VCS Repository.

but the overview below says vcs-repo, for example data.attributes.vcs-repo.branch, which doesn't work.

Description

Currently, there are terraform-plugin-sdk/v2 documentation pages which describe various Terraform Provider concepts, such as:

• Schemas
• Resources
• Data Sources (turns out we don't have a dedicated page for this 😢 )

terraform-plugin-framework, terraform-plugin-go, and terraform-plugin-mux also implement or reference these concepts in some fashion. There is no website documentation which succinctly correlates these concepts to the underlying protocol.

Proposal

Since the concepts themselves are not specific to the implementations and rather than duplicate content across all these pages, it seems ideal to:

• Create top level plugin development pages that is similar to the existing sdk/v2 page content (minus the sdk/v2 specific pieces) with links to sdk/v2, framework, go, and mux specific pages
  • Additionally, these top level pages should also link or reference the specific protocol RPCs involved (which maybe the protocol documentation needs to be expanded into its own page with references to each RPC)
• Pare down the sdk/v2 page to just reference links and the sdk/v2 specific content
• Create a framework page that is similar to the updated sdk/v2 page with framework-specific code
• When onboarded, create a go page that is similar to the updated sdk/v2 page with go-specific code
• Handle any necessary mux page changes/references

References

• hashicorp/terraform-website#2131

As a provider maintainer I got existing provider code. I would like to migrate progressively to the new code generation tool that is offered and based on openapi. Could you add content about how to migrate progressively to this new way of writing code?

How can I organize my code to make this migration as easy as possible? Where should the code generation configuration code live? How can I manage custom logic? How can I handle waiting operation when an operation in ongoing? How can I handle override and validation?

This content could help a lot to migrate to this new code generation phase of terraform plugin development :)

In the tutorial about code generation: website/docs/plugin/code-generation/workflow-example.mdx

Could you add support about how to generate documentation as well? Maybe with https://github.com/terraform-docs/terraform-docs or something similar

Do the markdown files generating the docs on the Terraform Registry for a provider supports Google Analytics Tracking?

Essentially, can we add this tag in the .md files and have the below tracking code added to each pages on the terraform provider registry documentation?

.. raw:: HTML
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-1234ABCD"></script>
    
    <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-1234ABCD');
    </script>

Documentation page: Private Registry > Managing Usage

You can even require that all of those modules use recent versions with a policy like this example on GitHub.

Example points to a non-existent file:
https://github.com/hashicorp/terraform-guides/blob/master/governance/third-generation/cloud-agnostic/http-examples/use-recent-versions-from-pmr.sentinel
Based on information the file has been moved to:
https://github.com/hashicorp/terraform-sentinel-policies/blob/main/cloud-agnostic/http-examples/use-recent-versions-from-pmr.sentinel

Hi, the Policies documentation page has the technical information hidden by the black navigation pane. But the width of the navigation pane is almost ridiculously wide. Is it possible to change this so that the information is readable instead of forcing people to scroll horizontally. Page in question - https://developer.hashicorp.com/terraform/cloud-docs/api-docs/policies