Provider and strong tie to region seems broken

[ghost]

This issue was originally opened by @bradrhod as hashicorp/terraform#18531. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Having a provider that requires a region, and then requiring any assets to be created in any other regions to have a alaised provider seems like the wrong model. Many assets have a region field in the asset, terraform should just be able to use that region field and create the asset. In particular Import is very broken.

For instance if you import a default google cloud project, it will have a 'default' network. That default network will have 17 default subnets. So to even get started creating something similar I have to create 17 providers all aliased the same way:

provider "google" {
region = "${var.default_region}"
project = "${var.project_name}"
}

provider "google" {
alias = "europe-west1"
region = "europe-west1"
project = "${var.project_name}"
}

provider "google" {
alias = "us-west1"
region = "us-west1"
project = "${var.project_name}"
}

provider "google" {
alias = "asia-east1"
region = "asia-east1"
project = "${var.project_name}"
}

provider "google" {
alias = "us-east1"
region = "us-east1"
project = "${var.project_name}"
}

provider "google" {
alias = "asia-northeast1"
region = "asia-northeast1"
project = "${var.project_name}"
}

provider "google" {
alias = "asia-southeast1"
region = "asia-southeast1"
project = "${var.project_name}"
}

provider "google" {
alias = "us-east4"
region = "us-east4"
project = "${var.project_name}"
}

provider "google" {
alias = "australia-southeast1"
region = "australia-southeast1"
project = "${var.project_name}"
}

provider "google" {
alias = "europe-west2"
region = "europe-west2"
project = "${var.project_name}"
}

provider "google" {
alias = "europe-west3"
region = "europe-west3"
project = "${var.project_name}"
}

provider "google" {
alias = "southamerica-east1"
region = "southamerica-east1"
project = "${var.project_name}"
}

provider "google" {
alias = "asia-south1"
region = "asia-south1"
project = "${var.project_name}"
}

provider "google" {
alias = "northamerica-northeast1"
region = "northamerica-northeast1"
project = "${var.project_name}"
}

provider "google" {
alias = "europe-west4"
region = "europe-west4"
project = "${var.project_name}"
}

provider "google" {
alias = "europe-north1"
region = "europe-north1"
project = "${var.project_name}"
}

provider "google" {
alias = "us-west2"
region = "us-west2"
project = "${var.project_name}"
}

resource "google_project" "project" {
name            = "${var.project_name}"
project_id      = "${var.project_id}"
billing_account = "${var.billing_account}"
}

This is a load of busy work just to get a region field in an asset to work, as you would expect it to work in the first place.

resource "google_compute_subnetwork" "europe-west1" {
name                     = "default"
network                  = "${google_compute_network.default.name}"
ip_cidr_range            = "10.132.0.0/20"
region                   = "europe-west1"
private_ip_google_access = "false"
}

Should not create a default network in region us-central1, it should be in region europe-west1.

The way that this happens on import is super clunky. Issuing a terraform import google_compute_subnetwork.asia-east1 default gets you a state file shown below. Note that the region for the asset coming from Google Cloud correctly says the region is asia-east1, but terraform clobbers that and puts the asset in us-central1. Not sure why.

You have to do a 'terraform import --provider="google.asia-east1" google_compute_subnetwork.asia-east1 default ` to get this to import as you would expect. This is actually somewhat hard to debug and figure all of this out.

"google_compute_subnetwork.asia-east1": {
"type": "google_compute_subnetwork",
"depends_on": [],
"primary": {
"id": "us-central1/default",
"attributes": {
"creation_timestamp": "2018-03-28T11:03:47.430-07:00",
"description": "",
"enable_flow_logs": "false",
"fingerprint": <snip>
"gateway_address": "10.128.0.1",
"id": "us-central1/default",
"ip_cidr_range": "10.128.0.0/20",
"name": "default",
"network": "https://www.googleapis.com/compute/beta/projects/test-project/global/networks/default",
"private_ip_google_access": "false",
"project": "test-project",
"region": "us-central1",
"secondary_ip_range.#": "0",
"self_link": "https://www.googleapis.com/compute/v1/projects/test-project/regions/us-central1/subnetworks/default"
},
"meta": {
"e2bfb730-ecaa-11e6-8f88-34363bc7c4c0": {
"create": 360000000000,
"delete": 360000000000,
"update": 360000000000
}
},
"tainted": false
},
"deposed": [],
"provider": "provider.google"
},

This import seems totally wrong. Would it not be easier just to have the region from the asset be used, as you would expect? On import from the cloud can we just not overwrite the region the provider sets?I think this is the same on all of the providers, so not specific to Google cloud.
It seems the provider created without an alias is just really carrying the 'default region'.

Am I not thinking about this correctly?

Terraform Version

Terraform v0.11.7

Expected Behavior

Actual Behavior

Steps to Reproduce

create a default google cloud project.
create a simple default google provider and project.
use terraform import google_compute_subnetwork.asia-east1 default' run terraform plan` and notice that wants to move asia-east1 default network to us-central1

References

https://groups.google.com/forum/#!topic/terraform-tool/P2r9mbcha2I
hashicorp/terraform#12512
hashicorp/terraform#15961

[bradrhod]

I believe this to be terraform issue, not a provider issue.

[morgante]

Should not create a default network in region us-central1, it should be in region europe-west1.

That is in fact how it works. There is no need to specify multiple providers if you're specifying the region directly on the resource—the region on the provider is only used as a default.

[nat-henderson]

Yep - a lot of our imports allow you to specify project/region/name as the import ID, and more and more will support that as we transition from our existing codebase to our codegen system. I'm going to close this issue, but please open another issue for any resource where you're experiencing this issue - we should fix the existing problems, even ahead of the codegen conversion.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!