Allow disk field in google_compute_instance to have a count parameter

[oridistor]

Terraform Version

0.8.4

Affected Resource(s)

• google_compute_instance

Terraform Configuration Files

resource "google_compute_instance" "node" {
count = "${var.number_of_nodes}"

name = "${format("node%d", count.index + var.first_node_id)}-${var.network_name}"
zone = "${var.region_zone}"
tags = ["${var.cluster_tag}", "${format("node%d", count.index + var.first_node_id)}"]

machine_type = "${var.machine_type}"

disk {
    image = "${lookup(var.machine_image, var.platform)}"
device_name = "os"
}

disk {
    type    = "local-ssd"
    scratch = true
device_name = "ephemeral"
}

network_interface {
    network = "${var.network_name}"

    access_config {
        # Ephemeral
    }
}

metadata {
    ssh-keys = "ubuntu:${file("${var.public_key_path}")}"
}

service_account {
    scopes = ["https://www.googleapis.com/auth/compute.readonly"]
}

}

Expected Behavior

I would've liked to be able to write count = 4 in the following segment:
disk {
type = "local-ssd"
scratch = true
device_name = "ephemeral"
}
so I can define several scratch disks at once, and then use count.index in device_name to differenitate between them.

Actual Behavior

Right now it's not possible, and I have to create a different module for any number of scratch disks I want to attach

[paddycarver]

Hey @oridistor! Sorry for the late reply. So you've got a couple things here worth commenting on.

The first is trying to set count on the disk part of your instance resource. That's not something Terraform supports, because count only works on resources; disk here is, as confusing as it sounds, a field in the instance resource. But the good news is it's largely there for convenience. You can use google_compute_disk to spin up a disk as its own resource, and that will work splendidly with count.

The second problem is a bit more fundamental, and I don't have a workaround for you at the moment: how to attach disks created with count to instances. You could spin up disks using the google_compute_disk resource and count, but you'd still have to specify disk blocks inside the instance resource to map them to the instance, which rather defeats the purpose.

I just talked with @danawillow today about #12398 and making attaching/detaching disks a bit easier, but I'm not sure that would cover this use case. Maybe it's worth having a google_compute_attached_disk resource that pulls it out, so we can use count on it. What do you think, @danawillow? It steps away from the API a bit, but is it worth it to make count work?

[danawillow]

Actually, the google_compute_disk resource is only for persistent disks, not scratch disks. We could have a separate google_compute_attached_disk resource which I think does solve both problems. In that case we'll just want to deprecate the disk field inside of google_compute_instance quickly. I'm starting to warm up to the idea of having it as a separate resource. I'll give that a shot in the other PR.

[danawillow]

So it turns out that attaching a disk later only works for persistent disks, not scratch disks. Unfortunately because of the way the API is, there's nothing we can do about that without a lot of extra hacking around. I'm going to go ahead and close this, but thanks again for reporting the issue and please keep them coming!

[smaslennikov]

@danawillow Sorry to bring this from the grave, but is it possible today to create a scratch disk outside of google_compute_instance, therefore allowing countable ones? Is this something planned for the future or simply a declined feature request?

Cheers!

[danawillow]

I'm taking a break from TF at the moment so I don't want to discuss this too much, but as far as I know there is not.
However, I believe TF 0.12 is going to allow expressions that would be similar to a count parameter: https://www.hashicorp.com/blog/hashicorp-terraform-0-12-preview-for-and-for-each.
(Also fyi the google provider issue tracker is at https://github.com/terraform-providers/terraform-provider-google, and we like keeping google provider-related conversations there if possible)

[smaslennikov]

@danawillow Thank you, I'll continue waiting on .12. If this is still not possible then, I'll make a new issue in the proper repository.

Cheers!

[ghost]

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.