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

google_compute_instance: network_interface constantly forces resource recreation #1394

Closed
gmiroshnykov opened this issue Apr 6, 2015 · 8 comments

Comments

@gmiroshnykov
Copy link

I've hit the following issue when trying to migrate from 0.3.7 to 0.4.0.

Basically, google_compute_instance is unusable, because it tries to recreate itself all the time.

Configuration:

resource "google_compute_instance" "test" {
    name = "test-instance"
    machine_type = "n1-standard-1"
    zone = "europe-west1-b"

    disk {
        image = "ubuntu-1404-trusty-v20150316"
        type = "pd-standard"
    }

    network_interface {
        network = "default"
    }
}

output "test" {
    value = "${google_compute_instance.test.name}"
}

First, I run terraform apply:

google_compute_instance.test: Creating...
  can_ip_forward:              "" => "0"
  disk.#:                      "" => "1"
  disk.0.auto_delete:          "" => "1"
  disk.0.image:                "" => "ubuntu-1404-trusty-v20150316"
  disk.0.type:                 "" => "pd-standard"
  machine_type:                "" => "n1-standard-1"
  metadata_fingerprint:        "" => "<computed>"
  name:                        "" => "test-instance"
  network_interface.#:         "" => "1"
  network_interface.0.address: "" => "<computed>"
  network_interface.0.name:    "" => "<computed>"
  network_interface.0.network: "" => "default"
  self_link:                   "" => "<computed>"
  tags_fingerprint:            "" => "<computed>"
  zone:                        "" => "europe-west1-b"
google_compute_instance.test: Creation complete

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Next, I run terraform plan with no changes to configuration:

-/+ google_compute_instance.test
    can_ip_forward:              "false" => "0"
    disk.#:                      "1" => "1"
    disk.0.auto_delete:          "true" => "1"
    disk.0.image:                "ubuntu-1404-trusty-v20150316" => "ubuntu-1404-trusty-v20150316"
    disk.0.type:                 "pd-standard" => "pd-standard"
    machine_type:                "n1-standard-1" => "n1-standard-1"
    metadata_fingerprint:        "hDGRxu_A09k=" => "<computed>"
    name:                        "test-instance" => "test-instance"
    network_interface.#:         "1" => "1"
    network_interface.0.address: "10.240.89.254" => "<computed>"
    network_interface.0.name:    "nic0" => "<computed>"
    network_interface.0.network: "https://www.googleapis.com/compute/v1/projects/my-project-name/global/networks/default" => "default" (forces new resource)
    self_link:                   "https://www.googleapis.com/compute/v1/projects/my-project-name/zones/europe-west1-b/instances/test-instance" => "<computed>"
    tags_fingerprint:            "42WmSpB8rSM=" => "<computed>"
    zone:                        "europe-west1-b" => "europe-west1-b"

As you can see, Terraform insists on recreating instance because network_interface.0.network value is different.

@gmiroshnykov
Copy link
Author

Might be related to #1286.

@MerlinDMC
Copy link
Contributor

I was just going to post the same issue after hitting that yesterday as well.
It seems to persist the self_link instead of the network name in the state but requires the actual network name for creation.

I did help me around that for now by editing the terraform config once the resource got created:

  network_interface {
    // network = "${google_compute_network.default.name}"
    network = "${google_compute_network.default.self_link}"
    access_config {
      // Ephemeral IP
    }
  }

which is a stupid way around this but getting me working again.

I'm currently looking for a way to turn the Network self_link into a usable name via the google api for submitting a patch - but so far I'm not that lucky.

Maybe the provider tests should have a case for testing the plan resolution after a resource got created and test for the number of needed transformations to be zero.

@MerlinDMC
Copy link
Contributor

This does fix my current problems in a first stupid way but I doubt it will fix the complete problem:

diff --git a/builtin/providers/google/resource_compute_instance.go b/builtin/providers/google/resource_compute_instance.go
index d89e82a..40a7fe6 100644
--- a/builtin/providers/google/resource_compute_instance.go
+++ b/builtin/providers/google/resource_compute_instance.go
@@ -3,6 +3,7 @@ package google
 import (
        "fmt"
        "log"
+       "path"
        "time"

        "github.com/hashicorp/terraform/helper/hashcode"
@@ -572,7 +573,7 @@ func resourceComputeInstanceRead(d *schema.ResourceData, meta interface{}) error
                        networkInterfaces = append(networkInterfaces, map[string]interface{}{
                                "name":          iface.Name,
                                "address":       iface.NetworkIP,
-                               "network":       iface.Network,
+                               "network":       path.Base(iface.Network),
                                "access_config": accessConfigs,
                        })
                }

@thijsschnitger
Copy link

I've hit this bug as well, using the workaround proposed by @MerlinDMC for now.

@phinze phinze closed this as completed in 8f717c3 Apr 8, 2015
phinze added a commit that referenced this issue Apr 8, 2015
@phinze
Copy link
Contributor

phinze commented Apr 8, 2015

Hey folks, just merged @dainis's fix into master. If that doesn't solve this issue, let me know and we can re-evaluate. 👍

@thijsschnitger
Copy link

worksforme thanks!

@gmiroshnykov
Copy link
Author

I can also confirm that this works, thanks a lot!

@ghost
Copy link

ghost commented May 3, 2020

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

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

No branches or pull requests

4 participants