dynamodb_table changing on every terraform apply

[chgangaraju]

Terraform Version

Terraform v0.11.0

Affected Resource(s)

• aws_dynamodb_table

Terraform Configuration Files

resource "aws_dynamodb_table" "foo" {
  name           = "foo"
  read_capacity  = 5
  write_capacity = 1
  tags           = "${var.tags}"
  hash_key       = "someId"
  range_key      = "id"

  attribute {
    name = "id"
    type = "S"
  }

  attribute {
    name = "someId"
    type = "S"
  }

  attribute {
    name = "someAttr"
    type = "S"
  }

  global_secondary_index {
    name            = "someAttr-index"
    hash_key        = "someAttr"
    read_capacity   = 5
    write_capacity  = 1
    projection_type = "ALL"
  }
}

Output

 ~ update in-place

Terraform will perform the following actions:

  ~ aws_dynamodb_table.foo
      global_secondary_index.2521064395.hash_key:             "someAttr" => ""
      global_secondary_index.2521064395.name:                 "someAttr-index" => ""
      global_secondary_index.2521064395.non_key_attributes.#: "0" => "0"
      global_secondary_index.2521064395.projection_type:      "KEYS_ONLY" => ""
      global_secondary_index.2521064395.range_key:            "" => ""
      global_secondary_index.2521064395.read_capacity:        "5" => "0"
      global_secondary_index.2521064395.write_capacity:       "1" => "0"
      global_secondary_index.4200371924.hash_key:             "" => "someAttr"
      global_secondary_index.4200371924.name:                 "" => "someAttr-index"
      global_secondary_index.4200371924.non_key_attributes.#: "0" => "0"
      global_secondary_index.4200371924.projection_type:      "" => "ALL"
      global_secondary_index.4200371924.range_key:            "" => ""
      global_secondary_index.4200371924.read_capacity:        "" => "5"
      global_secondary_index.4200371924.write_capacity:       "" => "1"

Plan: 0 to add, 1 to change, 0 to destroy.

Expected Behavior

It should not treat this as a change on every run.

Actual Behavior

Its treating this as a change and creating on every run.

Steps to reproduce/ More details

Table 1: hash_key, range_key, global_secondary_index with projection_type = "KEYS_ONLY" - Working
Table 2: hash_key, range_key, global_secondary_index with projection_type = "ALL" - Not working
Table 3: hash_key, global_secondary_index with projection_type = "KEYS_ONLY" - Working
Table 4: hash_key, global_secondary_index with projection_type = "ALL" - Working

[bflad]

I'm not sure AWS supports updating a GSI projection type: http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GlobalSecondaryIndexUpdate.html

So its certainly seems like a bug that the provider is not deleting and recreating the index in this case.

[apparentlymart]

Hi @chgangaraju! Sorry for this confusing behavior.

Based on the diff output here, it seems like Terraform's "refresh" step is not finding the secondary index when it reads the table back from the API. However, it is strange that this appears only to happen for that single table.

Do you see this error when the table is created from scratch with the index already applied, or does it appear only if the index is added to the table subsequently via an update? That would help to determine whether the bug is in the Create/Update functions or in the Read function.

If you're able to produce this with the simple configuration file you shared in the issue here, it'd be helpful if you could share the result of applying this configuration with the environment variable TF_LOG=trace set, which will give more detailed logging showing exactly what requests Terraform made to the DynamoDB API and what actions it took as a result. Since this result will be very long, please create a gist and share a link to it here.

[chgangaraju]

Sorry, I could not replicate the exact scenario now. Maybe i am getting newer version of aws provider. I haven't noted aws_provider version.

You can close this issue. I will reopen/create a new issue with the specified(more detailed) information, if i could reproduce this issue.

[ketanio]

+1 having the same issue with aws provider version v1.3.1 as well as v1.9.0.

[bflad]

@llKetanll can you open a new issue following the issue template with the latest version of the AWS provider (1.9.0 as of this writing)? We've been working on this recently and it would certainly help us know if we missed a use case, with full details. Thanks!

[jamesba]

I have seen a similar issue with v1.10.0, however the details are slightly different:

I have found that if "non_key_attributes" in a secondary index is not sorted into lexical order in the .tf file then the secondary index is torn down and recreated every run.

[bflad]

@jamesba can you open a new issue following the issue template so we can have the details? That sounds like it should be fairly trivial to fix.

[dansimau]

I am also experiencing the same behaviour as described in the issue and the sort order of non_key_attributes in the .tf file is already correct.

Using Terraform 0.11.7 and AWS provider version 1.17.0.

[dansimau]

Scratch that. The order is important, it's just that it's not necessarily lexical order. See #3807.

[vinod386]

I am still seeing this issue with terraform 0.11.11 and aws provider 1.59. I'm trying to import state of an existing table and run the plan against it. As explained in the above comments, I do not have any non-key attributes in the GSI as the projection type is ALL.

[vinod386]

nvm, I made a silly mistake (case sensitivity on a letter)

[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!