Upgrade from Legacy Provider for use with count, for_each, depends_on

[decoded4620]

This is a problem in general with the provider being a "legacy provider". We had planned enabling management of multiple logical databases on a shared Postgres instance - and we wrapped this functionality up into a module to enable this across multiple tenants to be managed within a single terraform configuration.

We have these wrapped modules created using a for_each loop, and since each instance of the module references a shared RDS postgres instance, we run into the problem of the provider not being able to be instantiated - due to its legacy nature.

The error is as follows:

│ Error: Module is incompatible with count, for_each, and depends_on
│ 
│   on main.tf line 117, in module "clients":
│  117:   for_each = ...
│ 
│ The module at
│ module.clients.module.cloudservice.module.postgres_database
│ is a legacy module which contains its own local provider configurations,
│ and so calls to it may not use the count, for_each, or depends_on
│ arguments.

Removing the postgresql provider from the module and passing it in would be required. But due to terraform alias restrictions this also is difficult to manage.

Will there be a plan to enable the provider:

provider "postgresql" {
  host      = "xxx"
  username  = "xxx"
  password  = "xxx"
  superuser = false
}

To be able to be instantiated with different configurations within a module created from a loop?

This has created an interesting barrier for us - and we'll have to move the management of logical databases out of terraform.

If there is more information needed - I'll be happy to dig deeper and add it. But this issue seems like an overall module technical barrier - so keeping it high level for the moment.

Terraform Version

Terraform v1.8.3

Affected Resource(s)

Please list the resources as a list, for example:

• postgresql provider

Terraform Configuration Files

Sorry these are proprietary

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

What should have happened?

Actual Behavior

What actually happened?

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-1234

[Keni]

is there a solution?

[rpaterson]

I just ran into this issue as well, but I don't think this provider is a "Legacy Provider" per se - the pattern of configuring a Provider within a Module is what is "legacy". Note the error message says "legacy module", not "legacy provider". Here's the relevant Terraform docs.

[rpaterson]

Arguably the problem could be "fixed" in this provider by allowing us to configure the database connection parameters at the resource level instead of the provider level?

[cyrilgdn]

I just ran into this issue as well, but I don't think this provider is a "Legacy Provider" per se - the pattern of configuring a Provider within a Module is what is "legacy".

@decoded4620 Is it a custom module or a public module? I think @rpaterson is right and the problem is that the provider "postgres" is defined directly in the module where you should pass the providers to the module with:

module "xxx" {
  source = "..."
  providers  = {
    postgresql.eu = ...
    postgresql.us = ...
  }

Arguably the problem could be "fixed" in this provider by allowing us to configure the database connection parameters at the resource level instead of the provider level?

w00t 😅 ?

that's the role of the provider setting in each resource

I allow myself to close this issue but don't hesitate to reopen it if I'm missing something.

[cpnielsen]

I just ran into this issue as well, but I don't think this provider is a "Legacy Provider" per se - the pattern of configuring a Provider within a Module is what is "legacy".

@decoded4620 Is it a custom module or a public module? I think @rpaterson is right and the problem is that the provider "postgres" is defined directly in the module where you should pass the providers to the module with:

module "xxx" {
  source = "..."
  providers  = {
    postgresql.eu = ...
    postgresql.us = ...
  }

Arguably the problem could be "fixed" in this provider by allowing us to configure the database connection parameters at the resource level instead of the provider level?

w00t 😅 ?

that's the role of the provider setting in each resource

I allow myself to close this issue but don't hesitate to reopen it if I'm missing something.

I cannot speak for @decoded4620, but our issue is that we want to create a module for creating a database along with some tables and default configuration. The database itself is handled with another provider (azure, aws, etc.), but then we want to use this provider to connect and set up the database. So each module needs to connect to a different database, meaning the provider must be set up inside the module, otherwise there's no way to dynamically use the module. And we cannot use the provider inside the module because terraform does not allow this.

So the only solution is to have the provider be the foundation without connection details and have a data source that refers to the actual database and manages the connection.