Provider configuration not inherited from parent module

[svenwb]

While using this module a terrform plan always requested to specify the region, although the variable region is set in the parent module.

Example

provider "aws" {
  assume_role {
    role_arn = "${var.aws_assume_role_arn}"
  }

  region = "${var.region}"
}

module "subnets" {
  source              = "git::https://github.com/cloudposse/terraform-aws-dynamic-subnets.git?ref=tags/0.11.0"
  availability_zones  = ["${data.aws_availability_zones.available.names}"]
  namespace           = "${var.namespace}"
  stage               = "${var.stage}"
  name                = "${var.name}"
  attributes          = "${var.attributes}"
  tags                = "${local.tags}"
  region              = "${var.region}"
  vpc_id              = "${module.vpc.vpc_id}"
  igw_id              = "${module.vpc.igw_id}"
  cidr_block          = "${module.vpc.vpc_cidr_block}"
  nat_gateway_enabled = "true"
}

>terraform plan
provider.aws.region
  The region where AWS operations will take place. Examples
  are us-east-1, us-west-2, etc.

  Default: us-east-1
  Enter a value: 

[lorengordon]

Does it help at all to pass the provider explicitly through the module?

module "subnets" {
  providers = {
    aws = "aws"
  }

  // ...
}

[lorengordon]

Also, how is var.region being passed in? What if you do: terraform plan -var <region>

[osterman]

@lorengordon that worked for me!

[GabeL7r]

It's because of this change 11 days ago to pin the provider version #51

IMO this is a breaking change because now everyone who sets any field in their provider block now has to pass the additional providers explicitly like @lorengordon stated.

[svenwb]

Hey @lorengordon yes if I pass the provider explicitly it works. Anyhow as I have a multi-project, multi-environment setup I expected to maintain the provider configuration at a central place in the terraform code.

[osterman]

@gabel0287 @svenwb @lorengordon

One of our constant problems maintaining 140 modules is that changes in providers happen constantly. We are a small team. Even if we had sufficient testing in place to continually test for regressions, we couldn’t fix them faster than terraform breaks them.

All of our modules are pre-1.0. In semver, this means the interface is subject to change at anytime. We try not to break it, but in this case it feels necessary.

Instead of pinning modules at the provider level, we could just document the version. But that is guaranteed to fall out of date because it’s not tested.

Instead of passing the provider explicitly, we could ask for the settings like region. But that means passing lots of other settings too.

Most modules today (ours and others) don’t pin the provider versions. But I am not convinced that is a best practice for aforementioned reasons.

I am not sure how we solve the problem in a better way that ensures stability in a consistent, documented, repeatable manner which is enforceable.

Any thoughts?

[osterman]

For references, Gruntworks does pinning as well. Rather than passing the provider, they are accepting the properties (e.g. region, and project)

https://github.com/gruntwork-io/terraform-google-gke/blob/master/main.tf#L6-L19

[aknysh]

addressed in https://github.com/cloudposse/terraform-aws-dynamic-subnets/releases/tag/0.15.0