Allow users to easily report provider bugs in the proper location

[bflad]

Current Terraform Version

Terraform v0.12.0-beta1

Use-cases

Some of Terraform's error messaging suggests creating an issue in a Terraform Provider's issue tracking:

        This is a bug in the provider, which should be reported in the provider's own
        issue tracker.

The location of this issue tracker may be ambiguous or not necessarily known by operators, especially for third-party Terraform Providers.

Proposal

It would be great to allow Terraform Providers to configure a new string value in their schema which can be inserted in these locations, such as:

        This is a bug in the provider, which should be reported in the provider's own
        issue tracker: https://github.com/terraform-providers/terraform-provider-aws/issues

I hesitate to say URL specifically because some third-party providers may prefer:

        This is a bug in the provider, which should be reported in the provider's own
        issue tracker: helpdesk@example.com

We can still fall back to the old message (ending with issue tracker.) if the new provider configuration is not present.

[apparentlymart]

This is a good idea and something I'd also like to do for the panic detector so that it can report a suitable location (other than this repository) to report to when a panic came from a plugin child process. Right now the messaging refers specifically to the Terraform Core repository, which I think will tend to misdirect even those who otherwise would know how to find the provider's own repository.

Another way we could do this is to have the registry decide where the appropriate issue-tracking location is and report it via its API at install time. With that extra indirection it'd be possible to move a provider to a new location over time and have its issue tracker location retroactively update, vs. potentially having a stale location hard-coded into the old releases forever.

[apparentlymart]

I was thinking about this a little more today, and specifically trying to put myself into the shoes of someone who saw the error message as currently written. What would I do if I didn't already know where the provider's issue tracker is?

With how we have the system set up today, I think I would note which provider the resource belongs to and go look at its doc section on the website, since that'll tend to be how I found out about this provider and this resource type in the first place.

With that said, I think a positive action we could take to easily improve on this today is to be explicit on the index page of the documentation for each provider about where it is developed and who to contact if you want to report an issue. This would hopefully also be an opportunity to generally advertise that the providers are developed independenty from Terraform Core -- a fact that is not particularly obvious today -- and may therefore make it easier for contributors to find the code and for those who want to report an issue not prompted by error messages to find the best places to report it.

In the long run we may be able to make this more systematic and even, as you suggest, integrate it directly into the error message. But a link in the docs is something we could do right now with no architectural changes at all, and I think it would be helpful even if issue tracker information is available directly in the error messages in the long run.

To try this out in a lightweight way without significantly changing the information architecture of the docs, perhaps we could start by just adding an extra paragraph to the leading words at the top of the provider's docs index page, like this:

AWS Provider

The Amazon Web Services (AWS) provider is used to interact with the many resources supported by AWS. The provider needs to be configured with the proper credentials before it can be used.

Use the navigation to the left to read about the available resources.

If you want to report a bug or feature request for this provider or its documentation, please see the AWS Provider's repository on GitHub.

Example Usage

(Etc, etc...)

[bflad]

@apparentlymart that is a great idea. 💯

Let me circle back with the other Ecosystem team members to see if we should consider doing this across the board, but we can certainly start with the AWS Provider. 👍

[rileykarson]

It's worth noting, Google and Azure have both added some of this information; see

• https://www.terraform.io/docs/providers/google/index.html

• https://www.terraform.io/docs/providers/azurerm/index.html

[paultyng]

I think this really should be a registry concern as well, if the provider was sourced from the registry, its support information can be funneled back through the registry to the appropriate location. The CLI can infer the registry landing page in 0.12 I believe, and that can probably be the appropriate landing page for support routing. Hard coding this in the provider will just cause drift and potential issues actually finding the proper reporting location (not to mention impacts of forking code, etc).

[paultyng]

The registry already has this button:

[radeksimko]

Agreed, that's a great idea @paultyng We could have a canonical URL, such as https://registry.terraform.io/providers/hashicorp/aws/<version>/issue which will redirect to GitHub or whatever else is set in the Registry.

With that said:

1. this redirect is not exposed from the Registry yet - so we should probably create a relevant task for the Registry team to get this done
2. When it is exposed we still need to implement this somehow into the SDK and/or core.

So while this issue may not represent how we are going to solve it, it still represents the unsolved problem.

For that reason I think we should keep it open until we have a replacement issue to link to.

[bflad]

Given this has been lingering for a long while and not really been highly requested or prioritized, closing to reduce issue noise.