Support for removal of feature block, as it conflicts with module for_each/count

ToniCipriani commented 2 years ago

(Note: This was originally an Azure provider feature request, so the content below is oriented toward that and in the Azure provider repository's issue template structure, not the Terraform repository's issue template structure.)

Community Note

Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Remove the requirement to define the feature block in the provider configuration.

When developing modules that uses the AzureRM provider, provider requires a provider { feature {} } block even when no additional configuration is required to the provider. This causes an issue when the module is used with Terraform 0.13+ for_each and count feature for defining repeated modules, where this is not allowed.

If the provider configuration is removed at the module level, this breaks the ability to individually test the module, e.g. deploying and planning it via Terratest, as we will get the "features {}" error.

Defining provider configuration within a module is considered a legacy pattern according to Hashicorp.

New or Affected Resource(s)/Data Source(s)

All

Potential Terraform Configuration

# Remove the requirement to define:

provider "azurerm" {
  feature {}
}

References

https://www.terraform.io/language/modules/develop/providers

A module intended to be called by one or more other modules must not contain any provider blocks. A module containing its own provider configurations is not compatible with the for_each, count, and depends_on arguments that were introduced in Terraform v0.13. For more information, see Legacy Shared Modules with Provider Configurations.

lonegunmanb commented 2 years ago

Hi @ToniCipriani , thanks for opening this issue. As Terraform's document said:

A module intended to be called by one or more other modules must not contain any provider blocks.

A module that intended to be used along with count or for_each is a module that intended to be called by other modules, so it must not contains provider blocks. An example module shows that a reusable module won't contains this provider block, but it will contains a terraform block` instead.

ToniCipriani commented 2 years ago

We are already following the terraform provider requirements format. However AzureRM still requires a features block if we need to run a plan. This is required in our case as our coding standards tests individual modules using Terratest, thus requires us to add provider { features {} ]. Unless features {} can be supplied via the terraform {} block?

tombuildsstuff commented 2 years ago

hey @ToniCipriani

Unfortunately we don't plan to remove the features block requirement, this is intentionally required so that users are aware of which behavioural features the provider is using (and avoid using a default provider block, pulling credentials from the Azure CLI/deploying resources into the wrong subscription).

Ultimately this is a Terraform Core/configuration question - the current implementation within Terraform Core requires that the provider block is configured at the top level and passed in - in the case of a test wrapper here you can do this in the test module itself.

Regarding potentially defining these values within the terraform block, ultimately that's a Terraform Core feature request and as such I'm going to transfer this issue to the hashicorp/terraform repository where someone from that team should be able to take a look.

Thanks!

ToniCipriani commented 2 years ago

@tombuildsstuff so I'm assuming that means what we are really asking for is Hashicorp to provide a way to supply the feature {} via provider requirements not as a provider configuration. To me provider requirements should work like partial configs.

apparentlymart commented 2 years ago

Thanks for sending this over to the Terraform Core repository, @tombuildsstuff!

From what I see here, it seems like it should be already possible to set this up the way intended by the current Terraform Core design:

Write the provider "azurerm" block in your root module only, containing the required features block.
If descendant modules will use that provider too, then either rely on the automatic inheritance of provider configurations or explicitly pass the provider configuration into the child modules using the providers meta-argument in your module blocks.
If you are working on a shared module that is developed independently of any particular configuration that calls it, then create a test root module inside that shared module's repository which you can use as a placeholder root module for testing purposes. That root module will contain the required provider block and a call to the shared module.

If you place your test configuration under tests/default, for example, then it could contain the following content:
```
terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
    }
  }
}

provider "azurerm" {
  features {}
}

module "main" {
  source = "../.."

  # (and optionally any input variables you need/want to set)
}
```
You can test by switching into that test root module directory and using Terraform workflow commands as normal.

I'm not sure I understand exactly what this feature request is representing now that it's in the hashicorp/terraform repository, since of course it was originally framed as an Azure provider feature request. Can you try what I've described above and let me know if that solves the problem? If not, it would help to know what didn't work so we can understand the root problem that this feature request is aiming to address, rather than any specific proposal to address it.

Thanks!

crw commented 10 months ago

I am doing clean-up on old waiting-response issues. As this issue has not seen a response since the previous post, I am going to close this. Please let me know if you are experiencing this issue and can answer the questions raised in the previous post. Thanks!

ToniCipriani commented 10 months ago

The issue still persist, but I have a workaround. In the pipeline, I only inject a separate provider block to run the test, but the module when used doesn't contain the block. Not a very clean solution but it solves the problem.

crw commented 10 months ago

OK, in that case it would be helpful to reframe this request for the core terraform product. See https://github.com/hashicorp/terraform/issues/31806#issuecomment-1249660482, particularly:

I'm not sure I understand exactly what this feature request is representing now that it's in the hashicorp/terraform repository, since of course it was originally framed as an Azure provider feature request. Can you try what I've described above and let me know if that solves the problem? If not, it would help to know what didn't work so we can understand the root problem that this feature request is aiming to address, rather than any specific proposal to address it.

This may be a bit much to process given that this issue is already been written and had a discussion, but if it is helpful this is what our new feature request form looks like: https://github.com/hashicorp/terraform/issues/new?assignees=&labels=enhancement%2Cnew&projects=&template=feature_request.yml

hashicorp / terraform