Open lwatterworth-cldr opened 4 years ago
If you want to pull the network details of host_project, you have to use host-project-id in data source where as rest of the config use your service-project-id
data "google_compute_network" "shared_vpc" {
name = <sharedvpc_host_network>
project = <sharedvpc_host_project_id>
}
@venkykuberan adding the project in there worked great -- but I do have "Owner" in both projects, which may sway results?
If this is indeed how things should work, and the problem was PEBKAC, could we spin this bug report into a documentation request? Add a line or two, explicitly calling this out, maybe include shared VPC as an example?
thanks for the support!
Hey @lwatterworth-cldr!
You raise an interesting point about the difference between gcloud
and Terraform with
While working in the service project, expecting to reference the shared VPC by it's full path name, as you can do with the gcloud CLI.
In Terraform (well, in the Google provider(s) at least) we've decomposed the full path/name of a resource into parts. So while gcloud
expresses the network as projects/{{project}}/global/networks/{{name}}
, in Terraform you'd express the same thing by filling in the project
and name
fields with the appropriate values. I'm not sure how we can make this change in expectations clear- doing it on every resource page is likely too heavy-handed, for example. Let me know if you have any ideas!
We do accept a path on some name
/reference fields, and parse the project out of there. We could also consider doing that more consistently. It presents a bit of a problem- if a user also specifies project
, there are 3 potential places the project is specified (project, resource, name/ref field) and we may need to use an unintuitive ordering for backwards compatibility reasons.
@rileykarson
When I specify the shared vpc as the network, subnetwork, it comes down to this conflict you mention.
resource google_container_cluster "my_cluster" {
project = "my-service-project"
network = "projects/my-shared-vpc-project/us-central1/networks/my-vpc"
subnetwork = "projects/my-shared-vpc-project/us-central1/subnetworks/my-subnet"
...
Result:
Error: googleapi: Error 404: Not found: project "my-service-project" does not have a subnetwork named "my-subnet" in region "us-central1"., notFound
Note the project id mixup.
Is my issue this bug, or should I file a new one?
A new one, thanks @jimsnab!
I think there needs to be a way to detect if a project is a service project or a host project by dat source. Or this should be an attribute of the project resource.
It should be added as an attribute of project's resource and datasource for sure- https://cloud.google.com/compute/docs/reference/rest/v1/projects/get contains xpnProjectStatus. I'd suggest filing that separately as an enhancement request through https://github.com/hashicorp/terraform-provider-google/issues/new?assignees=&labels=enhancement&projects=&template=01_enhancement.yml
Community Note
modular-magician
user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned tohashibot
, a community member has claimed the issue already.Terraform Version
Terraform v0.12.28 (also tried 0.13.3)
Affected Resource(s)
google_compute_network data source (possibly others)
Terraform Configuration Files
Debug Output
Expected Behavior
While working in the service project, expecting to reference the shared VPC by it's full path name, as you can do with the gcloud CLI.
Actual Behavior
no workie. seems that there is an assumption that (vpc) name will be project-local name, not a full path:
this'll do it every time: GET /compute/v1/projects/gcp-sharedvpc-service-project/global/networks/projects%2Fgcp-sharedvpc-host-project%2Fglobal%2Fnetworks%2Fshared-vpc
Steps to Reproduce
Important Factoids
"gcp-sharedvpc-host-project" has a VPC "shared-vpc", which is shared with "gcp-sharedvpc-service-project"