terraform-provider-aws: dynamodb-local plan / apply fails on UnknownOperationException for DescribeTimeToLive

Terraform Version

0.9.11 (also tested 0.9.8)

Affected Resource(s)

Please list the resources as a list, for example:

  • dynamodb_table

Terraform Configuration Files

# Configure the AWS Provider
provider "aws" {
  region     = "us-east-1"
  endpoints {
    dynamodb = "http://localhost:8000"
  }
}

resource "aws_dynamodb_table" "delete_me_table" {
  name           = "dev-delete-me"
  read_capacity  = 5
  write_capacity = 5
  hash_key       = "organization_uuid"
  range_key      = "created_at"

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

  attribute {
    name = "created_at"
    type = "N"
  }
}

Debug Output

https://gist.github.com/bglick/35899492e8ec5f9ab8908f5f24d863fa

Error is around line 50

Expected Behavior

Running plan after applying the first time should produce no changes

Actual Behavior

Error is generated, UnknownOperationException which is really dynamo returning a 400 for the call to dynamodb/DescribeTimeToLive

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply
  2. terraform plan

Important Factoids

  • Running against the latest version of dynamodb-local

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

  • hashicorp/terraform#14104 appears to be the PR where the feature was added that is causing the issue

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 7
  • Comments: 16 (4 by maintainers)

Most upvoted comments

Pull request on localstack fixing this issue https://github.com/localstack/localstack/pull/599

@vancluever Detecting the difference seems to be the big issue here. I can’t identify a non-hack call that could be made to figure it out.

Perhaps a good path is to add a local_mode option in the configuration and leave it to the user to explicitly set it on their test environments.

@Ninir I’ll try to get to documenting the list of calls against the most recent this week.

As far as Perhaps a good path is to add a local_mode option in the configuration and leave it to the user to explicitly set it on their test environments.. My point was that I think it will be very hard to detect whether we are talking to the “real” Dynamodb or the local version. If you’re using the local in a dev environment, you should be able to set a flag like local_mode to true directly in your .tf file.

This way the vast majority of executions that are not using the local version don’t have to have some sort of hack in the code to try to figure out if they’re touching the local server before executing (which could potentially introduce all sorts of bugs).