Import of google_compute_instance with metadata.startup-script set

[kartvep]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment
• If an issue is assigned to the "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 to "hashibot", a community member has claimed the issue already.

Terraform Version

terraform 0.12.6
provider google 2.13.0

Affected Resource(s)

• google_compute_instance

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key: https://www.hashicorp.com/security
# If reproducing the bug involves modifying the config file (e.g., apply a config,
# change a value, apply the config again, see the bug) then please include both the
# version of the config before the change, and the version of the config after the change.
resource "google_compute_instance" "instance" {
  depends_on   = [google_compute_disk.disk]
  count        = var.number
  name         = "${var.name}-${var.start_num + count.index}"
  machine_type = var.instance_type
  zone         = var.availability_zone
  labels       = {
    iow_name = local.label
  }

  boot_disk {
    initialize_params {
      image  = var.base_image
      size   = local.boot_size
      type   = local.boot_type
      labels = {
        boot_disk_label = "${local.label}-sda"
      }
    }

    auto_delete = var.disks_autodelete
  }

  dynamic "attached_disk" {
    for_each = local.disks
    content {
      source = "${var.name}-${var.start_num + count.index}-${
        element(split(":", attached_disk.value), 2)
      }"
    }
  }

  network_interface {
    network    = local.network
    subnetwork = local.subnetwork
    access_config {
      nat_ip = google_compute_address.instance_ip[count.index].address
    }
  }

  metadata = {
    startup-script = var.startup_script != "" ? var.startup_script : data.template_file.startup_script.rendered
  }

}

Expected Behavior

terrafrom import will write startup-script of instance to metadata.startup-script field of resource in terraform state. Changes in startup-script WILL NOT force instance to be replaced.

Actual Behavior

terraform import writes startup-script to metadata_starup_script field. terraform plan after import shows instance replacement - it tryes to move startup-script value from metadata_startup_script to metadata.startup-script and change to metadata_startup_script forces instance to be replaced.

Steps to Reproduce

1. terraform import google_compute_instance.instance instance-with-startup-script
2. terraform plan

[rileykarson]

This is the expected behaviour, for better or for worse, based on #1081. I'll document that, and then mark this issue as an enhancement to improve the behaviour for users who want the metadata.startup-script approach to work on import.

[paddycarver]

I think the direction we want to go with here is getting rid of the top-level metadata_startup_script field. It was historically added so we could make it recreate instances when it changed, but we can do that now in the map with CustomizeDiff, I believe. Unfortunately, I think that's a breaking change that will have to wait until 4.0.0.

[rick-pri]

This is the expected behaviour, for better or for worse, based on #1081. I'll document that, and then mark this issue as an enhancement to improve the behaviour for users who want the metadata.startup-script approach to work on import.

This is extremely dangerous default behaviour and completely opposite to how the startup-script value is interpreted elsewhere (i.e. not in Terraform). This should never have been accepted as the default for imports where users are typically coming from alternative systems that won't behave like this, and more importantly, without any way to override it.

Edited: We now have a use case for manually editing the state file.

[samiwel]

In case someone is looking for a workaround I recently ran into this exact issue and was able to get around by doing the following:

data "google_compute_instance" "default" {
  name = "vm-name"
  zone = "europe-west2-a"
}

resource "google_compute_instance" "default" {
  machine_type = var.machine_type
  name         = "vm-name"
  zone         = "europe-west2-a"

  metadata_startup_script = data.google_compute_instance.default.metadata.startup-script
}

[asl-cloud99]

@samiwel I am also facing the same issue. I am tying to import a existing compute instance resource into terraform. Terraform plan was success full but plan shows destroy and recreate.

~ metadata_startup_script = <<-EOT # forces replacement
            #!/bin/bash
          -
          +
            #Do something()
          -
          +
            # Do somthing()
          -
          +
            # Do somthing()
```

I there way to avoid recreate and destroy? 

[samiwel]

@samiwel I am also facing the same issue. I am tying to import a existing compute instance resource into terraform. Terraform plan was success full but plan shows destroy and recreate.

~ metadata_startup_script = <<-EOT # forces replacement
            #!/bin/bash
          -
          +
            #Do something()
          -
          +
            # Do somthing()
          -
          +
            # Do somthing()

I there way to avoid recreate and destroy?

@amitlaspal I was able to avoid destroying and re-creating the resource by defining a data source and referencing it in the metadata_startup_script attribute as demonstrated in my example above. Did this not work for you?

[github-actions]

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.