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

default value hashing error for AWS block_device (schema error?) #824

Closed
buth opened this Issue Jan 16, 2015 · 2 comments

Comments

Projects
None yet
4 participants
@buth
Contributor

buth commented Jan 16, 2015

The AWS instance resource allows for listing a set of block device mappings under block_device. I've run into an odd issue where if you do not specify the delete_on_termination attribute explicitly, the hash values computed from a Terraform file will never match one computed from the refreshed state.

In the case where you allow this attribute to be set to its default, you'll notice a line like this in the plan output.

block_device.1351955162.delete_on_termination: "" => "1" (forces new resource)

However if you look at the state file after applying the plan it reads slightly differently.

"block_device.2966244962.delete_on_termination": "true"

Not only is the saved value of the attribute different but because that value is included in the set hashing method Terraform reads this as a different block device all together. The result is that Terraform will never acknowledge that it has already correctly created the resource.

As mentioned above, you can fix this by explicitly setting the attribute.

delete_on_termination = true

I'm not totally sure where the bug is here. The hashing function itself seems sound, and I can't account for the different result. It does seem that perhaps this is a larger issue with the schema code and not just an idiosyncrasy of this resource.

@mitchellh

This comment has been minimized.

Member

mitchellh commented Jan 21, 2015

Notes: I would add a test in two places

  • TestResourceDataState - To test that setting a bool in a set to true results in "true"
  • TestSchemaMap_Diff - To test that the diff of a bool in a set results in "true" (instead of "1")

I expect the first will pass right now and the second will fail, but we want both tests in there to make sure we don't regress.

@egarbi

This comment has been minimized.

Contributor

egarbi commented Jan 21, 2015

Happening to me as well, as a workaround I need to run once with block defined and after that remove block_device from my code.
That is to prevent terraform to recreate the instance on every apply.

@phinze phinze self-assigned this Jan 22, 2015

phinze added a commit that referenced this issue Jan 27, 2015

[WIP] helper/schema: apply schema defaults at the field level when re…
…ading from config

We were waiting until the higher-level (m schemaMap) diffString method
to apply defaults, which was messing with set hashcode evaluation for
cases when a field with a default is included in the hash function.

refs #824

phinze added a commit that referenced this issue Jan 28, 2015

helper/schema: apply schema defaults at the field level when reading …
…from config

We were waiting until the higher-level (m schemaMap) diffString method
to apply defaults, which was messing with set hashcode evaluation for
cases when a field with a default is included in the hash function.

fixes #824

@phinze phinze closed this in #871 Jan 28, 2015

yahyapo pushed a commit to yahyapo/terraform that referenced this issue Mar 13, 2015

helper/schema: apply schema defaults at the field level when reading …
…from config

We were waiting until the higher-level (m schemaMap) diffString method
to apply defaults, which was messing with set hashcode evaluation for
cases when a field with a default is included in the hash function.

fixes hashicorp#824
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment