compute_instance: desired_state can only accept RUNNING value

[eraac]

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 v1.6.4
on darwin_arm64
+ provider registry.terraform.io/hashicorp/google v5.7.0
+ provider registry.terraform.io/hashicorp/google-beta v5.7.0

Affected Resource(s)

• google_compute_instance

Terraform Configuration Files

resource "google_compute_instance" "bastion" {
  name         = "bastion"
  machine_type = "f1-micro"
  zone         = "europe-west1-b"

  # instance is started/stopped via a Workflow
  desired_status = "TERMINATED"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  service_account {
    email  = google_service_account.bastion.email
    scopes = ["cloud-platform"] # all
  }
}

Debug Output

Panic Output

Expected Behavior

The instance should be created and turn-off

Actual Behavior

The terraform apply return an error

│ Error: 1 error occurred:
│       * When creating an instance, desired_status can only accept RUNNING value
│
│   with google_compute_instance.bastion,
│   on bastion.tf line 37, in resource "google_compute_instance" "bastion":
│   37: resource "google_compute_instance" "bastion" {

Steps to Reproduce

1. terraform apply

Important Factoids

References

Notes

I was able to create this resource with the same configuration before (probably before v5), furthermore the documentation mention the TERMINATED as a valid value.

b/313620109

[edwardmedia]

@eraac I tested on v4.5.0 and received the same error. Can you share the debug log for your apply on pre v5?

[eraac]

I just retry with the same version as my first apply (version 4.58) ... and got the same issue. I guess the first time I've probably set the desired_status after the first apply and didn't encounter this issue

I think we can transform this issue from bug to enhancement, is actually impossible to create an instance which is turn off (without a double apply), or worst when you want to add a lifecycle to ignore_changes from desired_status, you need to

• first apply (without lifecycle and desired_status)
• set desired_status to TERMINATED
• second apply
• set the lifecycle {ignore_changes=[desired_status]}

[edwardmedia]

@eraac I doubt there is much we can do in the Terraform. Are you able to create a brand new TERMINATED instance with other means, like gcloud?

[eraac]

@eraac I doubt there is much we can do in the Terraform. Are you able to create a brand new TERMINATED instance with other means, like gcloud?

If Terraform can turn off the instance on the second apply, I presume it can also turn it off in the first apply (I don't mind if the instance turn on for a few seconds). Similar to the way the google_container_cluster handles the default node pool, there are already some "post-processing" capabilities.

The real problem is the double apply + the manual edit required to have the desired state

[edwardmedia]

Theoretically I think yes a second call is added to change the state in the create. But I am not sure if that use case has high demand.

@zli82016 what do you think?

[zli82016]

Technically it is doable, but I don't think this use case has high demand. Normally, users don't want to create a instance and then immediacy terminate it.

[zli82016]

The request seems to be not potentially useful for users. I want the ticket to be retriaged.

[SarahFrench]

Note from triage: We're ok with the resource being updated to allow creation of terminated VMs

[Dutta78]

I saw that this can also hamper terraform deletion. Lets consider that we are creating a gcp instance and also a vault approle simultaneously.

Steps to reproduce

1. trigger the deletion and make sure that vault resources do not get deleted in first terraform destroy job.
   Make sure that desired_status="TERMINATED" at the time of deletion.
2. Terraform will destroy all the resources except vault resource.
   In the next destroy job it will throw this error.

Error: 1 error occurred:
	* When creating an instance, desired_status can only accept RUNNING value

Even though the instance has been deleted.
I haven't tested it with other resources but the result should be similar.

[karolgorc]

Wrote the code for this feature. Will submit a PR after this gets merged because I've already accounted for the SUSPENDED state's support.

@Dutta78 Can you please share your terraform config or more detailed steps to reproduce your error? I wasn't able to hit this while writing and testing the fix.

[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.