Add support for Interconnect VLAN attachments

[stxyzth]

The ability to order an interconnect itself is not something I imagine can be run through terraform being that it involves physical hands on the other side of the request.

The process for assigning VLAN attachments with an already established interconnect is something that could possibly be automated through Terraform, along with setting up the Hybrid Connectivity/Interconner cloud routers

https://cloud.google.com/interconnect/docs/how-to/dedicated/creating-vlan-attachments

[danawillow]

For reference, API is here: https://cloud.google.com/compute/docs/reference/rest/v1/interconnectAttachments.

I'm curious, I do see an interconnects API at https://cloud.google.com/compute/docs/reference/rest/v1/interconnects, which looks like it's for ordering an interconnect and then retrieving information about it. Would that be something useful to have too, or is that generally a process that would take place outside of a tool like Terraform?

The thing that makes me nervous about this resource is testing it- to test an attachment, we would need an established interconnect, which may or may not work for our automated tests depending on what sort of infra Hashicorp can set up, but definitely won't work for me running the test locally since I don't have a data center network that I can attach to. @paddycarver for opinions on how to handle this.

[stxyzth]

@danawillow

I'm curious, I do see an interconnects API at https://cloud.google.com/compute/docs/reference/rest/v1/interconnects, which looks like it's for ordering an interconnect and then retrieving information about it. Would that be something useful to have too, or is that generally a process that would take place outside of a tool like Terraform?

The ordering process requires a manual action not possible for the terraform applicator to complete. A google engineer is required to physically drop fiber from their demarc to your equipment in a cloud-rack.

Testing does become an issue unless there is a sandbox available to developers to run their code to. The logic here for the interconnect is like the need to specify a project to deploy under within GCP. The resource for the VLAN attachment would have a required argument for specifying the interconnect circuit id which is available in the cloud console/api after the service is provisioned by Google.

[amoiseiev]

I've been looking into this from our end. It's a gray area. Interconnect automation definitely fits into "everything is automated" scenario but has very limited use as this part of the infrastructure isn't fluid enough. It involves a procurement of physical hardware, wires etc. IMHO, building of automation for Google's side of it may add more entropy and potential failure cases than added benefits, in its current state.

[nickjacques]

We have a use case for Private Interconnect (still in Alpha) and would like to use Terraform to create/manage state for these objects as well. Like many network constructs (networks, subnets, etc), we do not expect to spin up/down these types of resources frequently, but rather would like to have the config and state stored for DR purposes.

Regardless of external state (ordering the physical interconnect or awaiting the Partner to turn up an InterconnectAttachment), it seems as though we could still create the resources, even if they require a manual out-of-band action to complete. In this way, companies can template-ize their network resources for use in multiple projects.

[jravetch]

I fully second @nickjacques request. I am also very interested in seeing Terraform GCP provider have the ability to add interconnect resources, as well as, attach them to specific VLANs.

[paddycarver]

The thing that makes me nervous about this resource is testing it- to test an attachment, we would need an established interconnect, which may or may not work for our automated tests depending on what sort of infra Hashicorp can set up, but definitely won't work for me running the test locally since I don't have a data center network that I can attach to. @paddycarver for opinions on how to handle this.

Thinking this through, I'm going to equate it to a reaaaaalllly annoying billing account or organization; we need one set up to run some of the tests, but we can't (AFAIK) set one up with the test framework, we need to do it manually. To that end, I'd say passing in the pre-existing interconnect resources would be the way to go, but the question of how expensive and maintenance-heavy it is to establish them comes up. I'd have to look more into how complicated and costly it is to set something like that up before I'd be able to say for sure whether we'd be able to test something like this or not. But similarly to the other manual-setup resources, I think being able to skip the tests if you don't want to set up the infrastructure is a must.

I'll check in with our team and see whether a testing interconnect is something we could conceivably set up, or if they have ideas for alternatives.

[jimmy-huang-ck]

@paddycarver @danawillow : Does the team have agreement on how best to move forward?

[paddycarver]

So my hangup on this is that we have no real way to test it on our end. We can't verify it works nightly like we do with the rest of the provider, and if someone reports a bug, we have no way to reproduce it on our end.

The upshot is I'm ok with this going in, but I'd really like some sort of warning for users on the docs page for it that--while we believe it works--the level of support for this resource is a bit lower than the rest of the provider.

[jimmy-huang-ck]

@paddycarver : thank you for being so careful in your approach. I agree with you about being explicit regarding the level of support to be expected, given testing is not possible. Having this resource supported in Terraform gives us the option to have more of our network infrastructure as code, so it would be a significant step in the right direction from our perspective.

[paddycarver]

I'll talk with the other maintainers--I have a meeting with them in 30 minutes--about our merge strategy for this and get an owner on it. I'm of the mindset that if you want to use this, you should be able to, but I just want people to be able to make an informed choice about the risks of it. :) I'll update either later today or tomorrow (I've got to catch a plane at some point...) with how we're going to move this forward. I think we're all agreed it will move forward, though.

[paddycarver]

Our plan is to auto-generate this resource, and my understanding is @ndmckinley is going to tackle it after he finishes with the resource he's currently generating.

[nat-henderson]

Hey, @jravetch, @jimmy-huang-ck, @stxyzth, and anyone else interested - I have #1569 which adds interconnect attachments. I'm not at all sure that it works, but it passes the sniff test - any of you willing to patch it in, try and create a resource, and tell me what happens (with debug logs)? I'd hate to release it without having tested it at all, but of course as @paddycarver says, I haven't got an interconnect to test it with.

[stxyzth]

Thanks @ndmckinley - we can at least run a first pass through it to ensure things import correctly from the already configured attachments and report back.

[Stewart-Smith-CK]

We have the resource imported correctly but wouldn't be able to test actual creation till a few weeks down the line.

It however imported what was manually created without any errors at all! Thanks @ndmckinley

google_compute_interconnect_attachment.us_central1_secondary: Importing from ID "prod-shared-vpc-host-project/us-central1/va-us-central1-to-us-central1-cloudrack-2"...
google_compute_interconnect_attachment.us_central1_secondary: Import complete!
  Imported google_compute_interconnect_attachment (ID: va-us-central1-to-us-central1-cloudrack-2)
google_compute_interconnect_attachment.us_central1_secondary: Refreshing state... (ID: va-us-central1-to-us-central1-cloudrack-2)

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.```

[paddycarver]

Does terraform show show the state you would expect?

[Stewart-Smith-CK]

@paddycarver Yes it shows what is expected:

google_compute_interconnect_attachment.us_central1_primary:
  id = va-us-central1-to-us-central1-cloudrack-1
  cloud_router_ip_address = 169.254.197.18/29
  creation_timestamp = 2018-02-13T13:49:09.109-08:00
  customer_router_ip_address = 169.254.197.19/29
  description = VLAN Attachment us-central1 Cloud Router to CloudRack 1
  google_reference_id = 
  interconnect = https://www.googleapis.com/compute/v1/projects/project1/global/interconnects/ix-us-central1-to-us-central1-cloudrack-1
  name = va-us-central1-to-us-central1-cloudrack-1
  operational_status = OS_ACTIVE
  private_interconnect_info.# = 1
  private_interconnect_info.0.tag8021q = 1000
  project = project1
  region = https://www.googleapis.com/compute/v1/projects/project1/regions/us-central1
  router = https://www.googleapis.com/compute/v1/projects/project1/regions/us-central1/routers/prod-shared-vpc-cr-us-central1
  self_link = https://www.googleapis.com/compute/v1/projects/REDACTED/regions/us-central1/interconnectAttachments/va-us-central1-to-us-central1-cloudrack-1

google_compute_interconnect_attachment.us_central1_secondary:
  id = va-us-central1-to-us-central1-cloudrack-2
  cloud_router_ip_address = 169.254.72.130/29
  creation_timestamp = 2018-02-13T14:23:31.741-08:00
  customer_router_ip_address = 169.254.72.131/29
  description = VLAN Attachment us-central1 Cloud Router to CloudRack 2
  google_reference_id = 
[...]

[paddycarver]

Excellent, thanks! If anyone is able to test actual creation, that would be amazing--I'm pretty uncomfortable shipping this without verifying at least once that it can actually create the resources in question.

I'm continuing to work on getting some way to test this on our end set up, but that could take some time.

[Stewart-Smith-CK]

@paddycarver within the next two weeks we should be able to test a creation of this resource type, I'll see if we can do it sooner but I'll keep you in the loop regardless. Thanks

[paddycarver]

Thanks so much! I can appreciate that an Interconnect is not a trivial piece of infrastructure and that it's disruptive to test creating it from scratch, so I'm super grateful you're willing to test this out for us.

[nmelepat]

I tried to test this but my requirement is slightly different as I am referring the interconnect which is configured in a different google project. Any thoughts to solve this?

[nat-henderson]

ping @Stewart-Smith-CK - did you get a chance to test that?
@nmelepat: You're trying to configure an Interconnect attachment, but the Interconnect is in a different project? You should be able to refer to the Interconnect by its full URL, which will include the project... does that not work for you?

[netturpin]

I tried it with a dedicated interconnect I'm working on and its looks good (plan, apply, show and destroy).
You can find the output here.

[nat-henderson]

Fantastic. I'll submit the PR. Thank you! :)

[alwaysastudent]

@ndmckinley have you issued the PR ? would love to use this.

[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 👉 hashibot-feedback@hashicorp.com. Thanks!