{"action":"closed","issue":{"url":"https://api.github.com/repos/hashicorp/terraform/issues/950","labels_url":"https://api.github.com/repos/hashicorp/terraform/issues/950/labels{/name}","comments_url":"https://api.github.com/repos/hashicorp/terraform/issues/950/comments","events_url":"https://api.github.com/repos/hashicorp/terraform/issues/950/events","html_url":"https://github.com/hashicorp/terraform/issues/950","id":56928345,"number":950,"title":"Non-determinism when value removed from configuration","user":{"login":"jefferai","id":28627,"avatar_url":"https://avatars.githubusercontent.com/u/28627?v=3","gravatar_id":"","url":"https://api.github.com/users/jefferai","html_url":"https://github.com/jefferai","followers_url":"https://api.github.com/users/jefferai/followers","following_url":"https://api.github.com/users/jefferai/following{/other_user}","gists_url":"https://api.github.com/users/jefferai/gists{/gist_id}","starred_url":"https://api.github.com/users/jefferai/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jefferai/subscriptions","organizations_url":"https://api.github.com/users/jefferai/orgs","repos_url":"https://api.github.com/users/jefferai/repos","events_url":"https://api.github.com/users/jefferai/events{/privacy}","received_events_url":"https://api.github.com/users/jefferai/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/hashicorp/terraform/labels/bug","name":"bug","color":"f7c6c7"},{"url":"https://api.github.com/repos/hashicorp/terraform/labels/core","name":"core","color":"cccccc"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-02-07T22:16:17Z","updated_at":"2015-02-18T18:52:23Z","closed_at":"2015-02-18T18:52:23Z","body":"This obsoletes #946.\r\n\r\nIt is possible for Terraform to get into two different states given the same configuration. Here's how it can be reproduced.\r\n\r\n1. Create a configuration file that does not set an Optional but non-Computed field.\r\n2. Apply the configuration. Note that the tfstate file does not show an entry for the field. At this time, calling GetOk will result in ok = false.\r\n3. Add a value for the field to the configuration.\r\n4. Apply the configuration. Note that the tfstate file shows an entry for the field matching the configuration. At this time, calling GetOk will result in ok = true.\r\n5. Remove the value for the field from the configuration.\r\n6. Apply the configuration. Note that the tfstate file shows an entry for the field of the default value. At this time, calling GetOk will result in ok = true.\r\n\r\nGiven 2 and 6, Terraform is in two different states given the same resource configuration. As Terraform is supposed to be idempotent, this is a bug. Code relying on GetOk to return an expected result will experience different answers based on the history of the resource rather than the actual configuration file.\r\n\r\nAs far as I can tell, the bug stems from the fact that Terraform handles removal of values from configuration by setting them to the default value for the type because there is no notion of removal of data from ResourceData.\r\n\r\nOne way to fix this would be to treat removal of a configuration field as a setting to the default value for that field for the purposes of calculating diffs and taking action; after action has been taken, those values should not be written to the tfstate file.\r\n\r\nAnother way to fix this might be to define an undefined type for the state file; when this is the state of the field, Exists (and thus GetOk) return false. This preserves the notion that the value was, at some point, set, but is not currently. In this solution, for consistency, all non-computed fields not currently defined in configuration should be defined in the tfstate file with the undefined type.\r\n\r\n@sparkprime as he's interested."}}