Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Importing resources with a project ID that differs to the provider project #1676

Closed
roobert opened this issue Jun 19, 2018 · 5 comments
Closed
Labels

Comments

@roobert
Copy link

roobert commented Jun 19, 2018

Hi,

As requested by @paddycarver I'm opening this issue to discuss a feature request regarding cross-gcp-project importing of resources.

It's is currently possible to create resource definitions which cannot be easily imported, specifically, when specifying the project parameter on a resource.

For example:

provider "google" {
  project     = "test0"
  region      = "europe-west1"
  version     = "~> 1.9"
}

terraform {
  backend "gcs" {
    bucket  = "terraform-state-test0"
  }
}

"resource" "google_dns_managed_zone" "example-com" {
  "name" = "example-com"
  "dns_name" = "example.com."
  "project" = "test1"
}

Although this config is valid and can be used to create/update/delete the managed zone for example-com in test1, if the zone exists already, it is not possible to import the resource into the state file using terraform import.

There are a couple of possibilities here:

  1. as suggested by @duckfez - create a secondary google provider with an alias such as google-test1 and then use terraform import -provider google-test1. This could potentially work and seems like the provider agnostic solution but is somewhat clumsy.

  2. update the terraform resources import templates to support including the project name.

e.g:

# instead of:
terraform import google_dns_managed_zone.prod prod-zone

# optionally specify the project:
terraform import google_dns_managed_zone.prod prod-zone test1

This solution would be the ideal solution, however I'm not sure if there are any standards or limitations on how terraform import should function regarding permitting additional parameters and allowing sensible defaults.

If limitations do exist and it's necessary to update all of the terraform import templates to include the project parameter, is it feasible and would that be an acceptable change?

# resource template which always specifies project since no default can be assumed:
terraform import google_dns_managed_zone.prod test1/prod-zone

If anyone can think of any other solutions I'd be interested in hearing them.

@roobert roobert changed the title Importing resources with project that differs to provider project and terraform import Importing resources with a project ID that differs to the provider project Jun 19, 2018
@roobert
Copy link
Author

roobert commented Jun 19, 2018

I've just noticed that some resources (specifically, the google_compute_global_address resource) supports specifying the project: https://www.terraform.io/docs/providers/google/r/compute_global_address.html#import

So it looks like this would be the best method to support this feature? If so I'd be happy to PR the change..

@paddycarver
Copy link
Contributor

Hey @roobert! Thanks for opening this bug, I appreciate it. As you mentioned, Global Addresses (and other resources) have a template of how we usually resolve this, and I think we'd like to follow that approach here, for consistency.

I see you've opened a PR for this. Thanks! I'll go ahead and review the code and we can hopefully get this fixed ASAP.

@sjungwirth
Copy link
Contributor

Just ran into this same issue with google_dns_record_set

@rileykarson
Copy link
Collaborator

rileykarson commented Feb 15, 2019

This was resolved for managed zone and any Magic Modules generated resources support this feature automatically. If anyone wants this on a specific resource that doesn't support it already, please file a new issue!

@ghost
Copy link

ghost commented Mar 18, 2019

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!

@ghost ghost locked and limited conversation to collaborators Mar 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants