openstack_compute_instance_v2.master: diffs didn't match during apply. This is a bug with Terraform and should be reported.

[jfchevrette]

Reporting as indicated by the error.

I am trying to provision a new instance from a volume instantiated from a source volume id.

resource "openstack_blockstorage_volume_v1" "myvol" {
  name = "myvol"
  size = "50"
  source_vol_id = "d35aad44-9af9-4047-9766-049a17d66623"
}

resource "openstack_compute_instance_v2" "myinstance" {
  name = "myinstance"
  flavor_id = "1601"

  block_device = {
    uuid = "${openstack_blockstorage_volume_v1.myvol.0.id}"
    source_type = "volume"
    destination_type = "volume"
    boot_index = "0"
    volume_size = "50"
  }

  network = { uuid = "55ed6f55-a305-4073-b5a3-99bd453e866c" }
}

First run of terraform apply results in the error mentioned in the issue title. If I run it a second time, the instance is created successfully.

terraform apply output: https://gist.github.com/jfchevrette/1e2ee15762efbd4df1a7
diff reason from TF_LOG=debug: https://gist.github.com/jfchevrette/f81d39464cc43c98f87e

[jtopjian]

Hi there,

I'm able to reproduce this. I'll look into it as soon as I can.

Thanks for reporting this. 😄

[jtopjian]

@phinze I've figure out the fix for this, but I don't understand why 😄

This issue only happens when the block_device.uuid attribute is set to a variable / exported value. In that situation, the following error is seen:

2015/12/03 03:58:22 [ERROR] openstack_compute_instance_v2.foo: diffs didn't match
2015/12/03 03:58:22 [ERROR] openstack_compute_instance_v2.foo: reason: extra attributes: block_device.0.delete_on_termination, block_device.0.boot_index, block_device.#, block_device.0.uuid, block_device.0.source_type, block_device.0.destination_type, block_device.0.volume_size

I'm able to fix this by creating a "proper" set function like this:

func resourceComputeBlockDeviceHash(v interface{}) int {
  var buf bytes.Buffer                                  
  m := v.(map[string]interface{})                       
  buf.WriteString(fmt.Sprintf("%s", m["uuid"].(string)))

  return hashcode.String(buf.String())                  
}                                                       

Rather than the one I stole from resource_aws_instance.go:

Set: func(v interface{}) int {                                            
  // there can only be one bootable block device; no need to hash anything
  return 0                                                                
},                                                                        

Why doesn't the above work in this situation? I read it as saying "no matter what values, just return 0 as a hashcode", so regardless of any changing values, it'd all be grouped under the same hashed set.

I need to make this change to block_device to support the request in #4042 anyway (funny how these things work out), but I'd like to know why the current code causes this particular issue.

[jtopjian]

Just had a thought: I think block_device might need to be a TypeList instead of a TypeSet. I was reviewing the API output I pasted in #4042 and noticed that:

1. The result set is an array
2. The last two elements are identical, so it'd be impossible to create a unique hash

I quickly rewrite block_device to be of TypeList and all seems well on first pass.

Thoughts?

[jfchevrette]

FYI, I'm pretty sure this was working fine not too long ago. Most likely some changes made in the recent versions caused this behaviour.

[jtopjian]

Do you build off of master frequently? The reason I ask is because until #3232 was merged, I'm pretty sure "boot from volume" was completely broke. If you do build off of master, then a patch between #3232 and recently could have affected this.

I'm definitely curious as to the cause (if recently) and why the fix I found fixes the problem. But regardless of those answers, I'm pretty sure I need to change block_device's internal type.

[phinze]

@jtopjian Hm this is almost definitely some sort of helper/schema bug. I think there's actually a cluster of bugs surrounding Sets and computed attributes that I'm poised to dive into. I've added this to the list.

Note when considering a conversion from TypeSet to TypeList that order must be respected in the API to avoid unexpected diffs on Lists. The fact that in the linked API output the block mapping contains two identical entries is pretty wonky though - is that expected behavior from the API?

Will follow up when I learn more about this computed set attribute mischief! 👍

[jtopjian]

@phinze Cool - thank you!

I totally agree about the wonkiness. I'll be looking into the API to ensure that the order is always consistent -- I think that's the only sane explanation for identical elements. 😄

[shockinghobby]

Just hit the same bug. The only difference is that the cinder volume is created from the image_id, not the source_vol_id.

resource "openstack_compute_instance_v2" "test-server" {
    name = "Test"
    image_id = "d321a0fb-19e1-4557-a126-6ef4e6e87dba"
    image_name = "CentOS 7 64-bit"
    flavor_id = "fc4c3410-f0f9-456a-8810-16a9ea6df80a"
    flavor_name = "s1.small"
    key_pair = "key"
    block_device {
        uuid = "${openstack_blockstorage_volume_v1.volume_1.id}"
        boot_index = "0"
        source_type = "volume"
        volume_size = "10"
        destination_type = "volume"
    }
    network {
        name = "nat"
    }
}

resource "openstack_blockstorage_volume_v1" "volume_1" {
    image_id = "d321a0fb-19e1-4557-a126-6ef4e6e87dba"
    name = "tf-test-volume"
    description = "first test volume"
    size = 10
    volume_type = "basic"
}

[jtopjian]

@jfchevrette @shockinghobby I've just committed a fix that should resolve this issue. If you're able to compile and test from source, please let me know if you're still encountering issues.

[shockinghobby]

Looks like it is fixed. No issues so far. Awesome. Thank you.

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