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

Unexpected machine re-creation while using resource google_notebooks_instance #8216

Closed
ghost opened this issue Jan 14, 2021 · 4 comments · Fixed by GoogleCloudPlatform/magic-modules#4403, hashicorp/terraform-provider-google-beta#2880 or #8246
Assignees
Labels

Comments

@ghost
Copy link

ghost commented Jan 14, 2021

This issue was originally opened by @skymarchettis as hashicorp/terraform#27494. It was migrated here as a result of the provider split. The original body of the issue is below.


Hi,
I'm using the google_notebooks_instance resource but I'm giving unexpected behaviors while trying to change it.
After a variable value change, only an in-place update should be performed for the resource which is destroyed and recreated instead.
Using the console, these changes can be done in "hot" mode while keeping the same machine.

Terraform Version

Terraform v0.12.28
+ provider.google v3.52.0

Terraform Configuration Files

resource "google_notebooks_instance" "ai-notebook" {
    # ... configurations ...

    no_remove_data_disk = lookup(each.value, "no_remove_data_disk", false)
    metadata = {
      "proxy-mode" = "mail"
      "enable-oslogin" = "TRUE"
      "notebook-disable-root" = "TRUE"
      "startup-script" = <<EOF
      #!/bin/bash
      shutdown -h now
      EOF
    }
}

Expected Behavior

  # module.module-name.google_notebooks_instance.ai-notebook["instance"] will be updated in-place
-/+ resource "google_notebooks_instance" "ai-notebook" {
     # ... configurations ...

      ~ metadata            = {
            "enable-oslogin"        = "TRUE"
            "notebook-disable-root" = "TRUE"
            "proxy-mode"            = "mail"
          ~ "startup-script"        = <<~EOT
              - /path/to/script/script.sh
              +       #!/bin/bash
              +       shutdown -h now
            EOT
        }

      ~ no_remove_data_disk = false -> true
    }

Plan: 5 to add, 4 to change, 1 to destroy.

Actual Behavior

  # module.module-name.google_notebooks_instance.ai-notebook["instance"] must be replaced
-/+ resource "google_notebooks_instance" "ai-notebook" {
     # ... configurations ...

      ~ metadata            = { # forces replacement
            "enable-oslogin"        = "TRUE"
            "notebook-disable-root" = "TRUE"
            "proxy-mode"            = "mail"
          ~ "startup-script"        = <<~EOT
              - /path/to/script/script.sh
              +       #!/bin/bash
              +       shutdown -h now
            EOT
        }

      ~ no_remove_data_disk = false -> true # forces replacement
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Additional Context

Another strange behavior is that if a resource was created with no_remove_data_disk = true, it's created correctly with keep disk enabled. But if I run the plan again, the output shows ~ no_remove_data_disk = false -> true

@skymarchettis
Copy link

There's the same behaviour if you try to change the machine_type value.

# google_notebooks_instance.ai-notebook["instance"] must be replaced
-/+ resource "google_notebooks_instance" "ai-notebook" {
      ...
      ~ machine_type        = "n1-standard-4" -> "n1-standard-8" # forces replacement

When, doing the same operation via UI, you just have to turn off the machine and change type.

@skymarchettis
Copy link

Hi, I tried to execute the same command using the new provider version

➜  terraform ✗ terraform version
Terraform v0.12.28
+ provider.google v3.53.0

but I still have the same behaviour.

@edwardmedia
Copy link
Contributor

@skymarchettis it has been built into below version. Can you try it and let me know the result?

https://github.com/hashicorp/terraform-provider-google/releases/tag/v3.54.0

@ghost
Copy link
Author

ghost commented Feb 19, 2021

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 as resolved and limited conversation to collaborators Feb 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.