search

hashicorp / terraform-provider-google

Terraform Provider for Google Cloud Platform
https://registry.terraform.io/providers/hashicorp/google/latest/docs
Mozilla Public License 2.0
2.33k stars 1.73k forks source link

Error creating instance: googleapi: Error 503: Internal error on google_compute_instance_from_template resource #9260

Closed davidg251 closed 1 month ago

davidg251 commented 3 years ago

Community Note

Terraform Version

on linux_amd64
+ provider registry.terraform.io/hashicorp/google v3.69.0

Affected Resource(s)

Terraform Configuration Files

I'm using the example to create a new instance template https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_instance_template . Terraform is creating the template successfully. But for the VM Google API is showing the error on Debug Output section.

With this file terraform apply doesn't work. https://gist.github.com/nan140114/2791cce40e746073f99ee96f5e8d9994

After remove the resource_policies = [google_compute_resource_policy.daily_backup.id] on disk block. It works. With this file terraform apply does work. https://gist.github.com/nan140114/0f80d962876be5a808f5db51ed55e6b4

I tried creating the a new VM from the template via GCP Console and it worked.

Debug Output

https://gist.github.com/nan140114/31651576f90ee48e9e7d910bffddae9e

Panic Output

Expected Behavior

A new virtual created from the specified instance template

A new VM created from the template

Actual Behavior

Error on VM creation.

Steps to Reproduce

  1. terraform init
  2. terraform plan -var-file=./envs/development.tfvars
  3. terraform apply -auto-approve -parallelism=1 -var-file=./envs/development.tfvars

    Important Factoids

The terraform plan is OK.

References

b/308756318

edwardmedia commented 3 years ago

We should send the id instead of the name for resourcePolicies. Below is the current implementation which has the problem

POST /compute/beta/projects/projects/myproject/zones/us-central1-a/instances?alt=json&prettyPrint=false&sourceInstanceTemplate=projects%2Fmyprojectt%2Fglobal%2FinstanceTemplates%2Fissue9260 
Host: www.googleapis.com

{
 "disks": [
  {
   "autoDelete": true,
   "boot": true,
   "deviceName": "persistent-disk-0",
   "initializeParams": {
    "diskType": "zones/us-central1-a/diskTypes/pd-standard",
    "resourcePolicies": [
     "issue9260"
    ],
    "sourceImage": "projects/debian-cloud/global/images/family/debian-9"
   },
   "interface": "SCSI",
   "kind": "compute#attachedDisk",
   "mode": "READ_WRITE",
   "type": "PERSISTENT"
  }
 ],
 "metadata": {},
 "name": "instance-from-issue9260",
 "scheduling": {
  "automaticRestart": true,
  "onHostMaintenance": "MIGRATE"
 },
 "tags": {},
 "zone": ""
}
edwardmedia commented 3 years ago

Noticed the data format of resourcePolicies, it is a shortname returned from api but when creating an instance, it requires the format like projects/%s/regions/%s/resourcePolicies/%s. The provider rely on whatever returned from api of the template to create an instance.

Add label to upstream

osuarez84 commented 2 years ago

I am facing the same issue here when using the example to develop my module code. Is there any work around to make this work?

davidg251 commented 2 years ago

I just removed the block.

ndlanier commented 2 years ago

Was there ever a workaround or resolution to this. Currently running into this issue

melinath commented 1 year ago

It looks like we have workarounds for similar cases for disk.initialize_params.disk_type and disk.source_image: https://github.com/hashicorp/terraform-provider-google/blob/4a1460e095d64cbfade02da4207a66bbbf860894/google/resource_compute_instance_from_template.go#L223 According to the comment, this code has to always override the disks to allow field overrides to work correctly on a per-disk basis.

However, we don't actually currently support disk resource policies on compute instances at all - we just modify the array of disks to add whatever was on the instance template. Since instance templates support disk resource policies, those can get passed through to compute instances implicitly without their formatting getting updated to specify a full path.

I think this is not actually an upstream bug. Ideally the behavior here would be:

melinath commented 1 year ago

In terms of workarounds - managing compute instances directly or using google_compute_instance_group_manager may be a better option.

melinath commented 1 year ago

I wonder if we could consider making this resource not try to override any fields if no overrides are provided on the resource.

lebenitza commented 9 months ago

Another workaround would be to just use this resource instead of attaching the resource policy on the disk in the template instance:

resource "google_compute_disk_resource_policy_attachment" "<redacted>" {
  name = google_compute_resource_policy.weekly_backup_euw4.name
  disk = google_compute_instance_from_template.<redacted>.name
  zone = google_compute_instance_from_template.<redacted>.zone
}

The trick being that the root disk will have the same name as the VM itself. Of course, this won't work as easy for additional disks.

The fix still remains implemeting this in the provider:

I think this is not actually an upstream bug. Ideally the behavior here would be:

  • google_compute_instance supports disk resource policies
  • google_compute_instance_from_template handles fixing disk resource policy references
karolgorc commented 2 months ago

Working on a pr supporting disk resource policies on instance

github-actions[bot] commented 3 weeks ago

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.