Skip to content
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

dynamodb-local plan / apply fails on UnknownOperationException for DescribeTimeToLive #1059

Closed
bglick opened this issue Jul 4, 2017 · 16 comments
Labels
bug Addresses a defect in current functionality. service/dynamodb Issues and PRs that pertain to the dynamodb service. stale Old or inactive issues managed by automation, if no further action taken these will get closed. upstream Addresses functionality related to the cloud provider.

Comments

@bglick
Copy link

bglick commented Jul 4, 2017

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:

@vancluever
Copy link
Contributor

It goes farther than DescribeTimeToLive, unfortunately (which isn't apparently supported by DynamoDB local). ListTagsOfResource seems to be having the same issue:

2017/07/06 15:53:54 [DEBUG] plugin: terraform: -----------------------------------------------------
2017/07/06 15:53:54 [DEBUG] plugin: terraform: aws-provider (internal) 2017/07/06 15:53:54 [DEBUG] [aws-sdk-go] DEBUG: Request dynamodb/ListTagsOfResource Details:
2017/07/06 15:53:54 [DEBUG] plugin: terraform: ---[ REQUEST POST-SIGN ]-----------------------------
2017/07/06 15:53:54 [DEBUG] plugin: terraform: POST // HTTP/1.1
2017/07/06 15:53:54 [DEBUG] plugin: terraform: Host: localhost:32771
2017/07/06 15:53:54 [DEBUG] plugin: terraform: User-Agent: aws-sdk-go/1.8.13 (go1.8; linux; amd64) APN/1.0 HashiCorp/1.0 Terraform/0.9.4
2017/07/06 15:53:54 [DEBUG] plugin: terraform: Content-Length: 66
2017/07/06 15:53:54 [DEBUG] plugin: terraform: Accept-Encoding: identity
2017/07/06 15:53:54 [DEBUG] plugin: terraform: Authorization: AWS4-HMAC-SHA256 Credential=foo/20170706/ca-central-1/dynamodb/aws4_request, SignedHeaders=accept-encoding;content-length;content-type;host;x-amz-date;x-amz-target, Signature=xxxx
2017/07/06 15:53:54 [DEBUG] plugin: terraform: Content-Type: application/x-amz-json-1.0
2017/07/06 15:53:54 [DEBUG] plugin: terraform: X-Amz-Date: 20170706T225354Z
2017/07/06 15:53:54 [DEBUG] plugin: terraform: X-Amz-Target: DynamoDB_20120810.ListTagsOfResource
2017/07/06 15:53:54 [DEBUG] plugin: terraform: 
2017/07/06 15:53:54 [DEBUG] plugin: terraform: {"ResourceArn":"arn:aws:dynamodb:ddblocal:000000000000:table/foo"}
2017/07/06 15:53:54 [DEBUG] plugin: terraform: -----------------------------------------------------
2017/07/06 15:53:54 [DEBUG] plugin: terraform: aws-provider (internal) 2017/07/06 15:53:54 [DEBUG] [aws-sdk-go] DEBUG: Response dynamodb/ListTagsOfResource Details:
2017/07/06 15:53:54 [DEBUG] plugin: terraform: ---[ RESPONSE ]--------------------------------------
2017/07/06 15:53:54 [DEBUG] plugin: terraform: HTTP/1.1 400 Bad Request
2017/07/06 15:53:54 [DEBUG] plugin: terraform: Connection: close
2017/07/06 15:53:54 [DEBUG] plugin: terraform: Content-Type: application/x-amz-json-1.0
2017/07/06 15:53:54 [DEBUG] plugin: terraform: Server: Jetty(8.1.12.v20130726)
2017/07/06 15:53:54 [DEBUG] plugin: terraform: X-Amzn-Requestid: xxxx
2017/07/06 15:53:54 [DEBUG] plugin: terraform: 
2017/07/06 15:53:54 [DEBUG] plugin: terraform: {"__type":"com.amazonaws.dynamodb.v20120810#UnknownOperationException","message":"An unknown operation was requested."}
2017/07/06 15:53:54 [DEBUG] plugin: terraform: -----------------------------------------------------

Probably means that several calls are going to need to be skipped in the event of DynamoDB local (and it will have to be detected somehow).

@stack72 stack72 added the bug Addresses a defect in current functionality. label Jul 7, 2017
@bglick
Copy link
Author

bglick commented Jul 8, 2017

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

@vancluever
Copy link
Contributor

Yeah, I agree. I don't see that being a really invasive change either and it will be easy to check against when making calls.

@bglick
Copy link
Author

bglick commented Jul 10, 2017

I'm not a Go developer, so I won't be able to write the patch, but if it helps, I could run through the current DynamoAPI and identify all of the calls that currently fail and report back the list. Just let me know.

@Ninir
Copy link
Contributor

Ninir commented Aug 4, 2017

Hey folks,

To resume, this issue is happening ONLY when using a local DynamoDB, with new API Calls unsupported by the local API (describe TTL, probably Accelerator, tags, ...).
Using the provided config without the provider one works as expected.

At this point, the only thing we could do is to catch the UnknownOperationException..

@bglick could you check using the latest version of the local DynamoDB? Also, what do you mean by 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.? not sure to get the point here.

Thanks!

@Ninir Ninir added the waiting-response Maintainers are waiting on response from community or contributor. label Aug 4, 2017
@radeksimko radeksimko added the upstream Addresses functionality related to the cloud provider. label Aug 7, 2017
@stevenao
Copy link

stevenao commented Aug 8, 2017

It looks me it is more of a bug from the AWS side that they miss to take care in DynamoDB local.

@bglick
Copy link
Author

bglick commented Aug 19, 2017

@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).

@nterry
Copy link

nterry commented Oct 18, 2017

@stevenao Agreed, the ttl should be a stub, at least. The fact that we have to patch around this is absurd

@stevenao
Copy link

stevenao commented Nov 2, 2017

Someone should press AWS to handle those operations in their dynamodb local implementation. They can always just do no-op and let the api through. It is not hard to add. As a matter of fact, one can create a reverse proxy and handle the new operations api, but forward the known ones to dynamodb local instance.

@paddycarver paddycarver removed the waiting-response Maintainers are waiting on response from community or contributor. label Nov 21, 2017
@ben-bourdin451
Copy link

@stevenao I had the same thought about a reverse proxy and found a potential candidate in this repo however just from looking at the code it seems that it doesn't do what we need it to.

I'm wondering how difficult this would be to implement, or if it's even worth it 🤔 That is of course if no-one else has already done this...

@stevenao
Copy link

stevenao commented Dec 3, 2017

@ben-bourdin451 Local-Stack. That stuff looks a little overwhelming to me. Anyways, I put together a POC into a new repo (https://github.com/stevenao/dynamodb-local-mock-unsupported-api). It is currently mocking out the Tagging and TTL api. It is simply running a nodejs api server in front of the dynamodb-local api server to provide mocks to the unsupported api's.

@ben-bourdin451
Copy link

@stevenao Thanks for that! I briefly tested this today and had some issues but I will comment on your repo 😄

@osama-afifi
Copy link

Pull request on localstack fixing this issue localstack/localstack#599

@stefansundin
Copy link
Contributor

stefansundin commented Oct 13, 2018

I just created a PR to work around the issue reading tags (#6149). I wasn't able to reproduce the issue with TTL. Maybe they fixed it with the more recent dynamodb-local versions? Can anyone confirm this?

It looks like dynamodb-local doesn't support setting TTLs (persistent diff), but Terraform does not seem to crash for me.

UPDATE: Found this in the release notes in the zip file (from here).

2017-04-13 (1.11.119)

  • Add TTL implementation
  • Update aws libs to 1.11.119

But this date is earlier than when this issue was opened. Was an old version used perhaps?

@github-actions
Copy link

github-actions bot commented Oct 3, 2020

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

@github-actions github-actions bot added the stale Old or inactive issues managed by automation, if no further action taken these will get closed. label Oct 3, 2020
@github-actions github-actions bot closed this as completed Nov 2, 2020
@ghost
Copy link

ghost commented Dec 3, 2020

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!

@ghost ghost locked as resolved and limited conversation to collaborators Dec 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality. service/dynamodb Issues and PRs that pertain to the dynamodb service. stale Old or inactive issues managed by automation, if no further action taken these will get closed. upstream Addresses functionality related to the cloud provider.
Projects
None yet
Development

No branches or pull requests