-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
implement new DDB streams provider using DynamoDB-Local #11688
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
Conversation
a6c5733
to
8431fa2
Compare
S3 Image Test Results (AMD64 / ARM64) 2 files 2 suites 3m 50s ⏱️ Results for commit e1f4bd9. ♻️ This comment has been updated with latest results. |
LocalStack Community integration with Pro 2 files 2 suites 1h 42m 31s ⏱️ Results for commit e1f4bd9. ♻️ This comment has been updated with latest results. |
7dcda6e
to
03512db
Compare
hey folks! i helped narrow down the reviewers to @dfangl and @viren-nadkarni 🙏 |
03512db
to
3bbc6a1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a fantastic change 👏 Kudos!
I'm not sure I like the v1 provider code copied but it makes practical sense. We should deprecate the v1 provider at the earliest and make v2 the default to reduce any maintenance burden.
We also have the upgrade to DDBLocal v2 in the pipeline #11064. This will be a low-level change and should not cause confusion with regards to the v2
marker.
localstack-core/localstack/services/dynamodbstreams/v2/provider.py
Outdated
Show resolved
Hide resolved
def modify_stream_arn_for_ddb_local(self, stream_arn: str) -> str: | ||
parsed_arn = parse_arn(stream_arn) | ||
|
||
return f"arn:aws:dynamodb:ddblocal:000000000000:{parsed_arn['resource']}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any idea how well this plays when non-default account/region is used in the request context?
Would the ARN in the response returned by DDBLocal need to be updated too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idea no, I'll give it a try quickly to see, thanks for pointing it out!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ARN returned by DDBLocal are being updated by the following service response handler: localstack.services.dynamodb.utils.modify_ddblocal_arns
.
I've checked and the needed StreamArn is always the 000000000000
account id and ddblocal
region, works properly with non default account and region 👍 thanks for checking! (sharding seems to be done on the credentials level)
@viren-nadkarni I definitely agree, I don't like it very much either... but the changes are so big that subclassing it made it difficult, and the other way would have been to introduce a feature flag to disable the streams feature in the DDB provider and only implement the DDB Streams v2 provider, but it would have been a lot of weird code paths. 😕 Also, we're still missing a feature in v2 with the KinesisStreamDestination that we need to think about how to implement, with maybe a poller on the DDB streams themselves, but we would need to change the overall configuration and modify the resulting payload from |
Co-authored-by: Daniel Fangl <daniel.fangl@localstack.cloud>
This reverts commit 8ca6971.
3bbc6a1
to
e1f4bd9
Compare
Motivation
First commit is based on 6f294e8
As reported by some of our users and also in #11599, DynamoDB-local supports DynamoDB Streams out of the box. This PR remove the current logic we had to support the stream functionality (using Kinesis under the hood) and which had to often query DDB-local multiple times for one request to get the old and/or new images.
This adds a considerable performance boost: we don't need to query ddb, and we reduce our internal usage of kinesis which reduces load on our gateway.
We only need to manipulate the headers + do some payload manipulation to modify the returned region, and update it before forwarding it to ddb local.
These are quite big, so we are releasing them under a new provider for now behind a feature flag (the usual
PROVIDER_OVERRIDE_DYNAMODBSTREAMS=v2
). Question is, is it DynamoDB v2 or DynamoDBStreams v2? The 2 implementations are tied together, and DynamoDB is shorter, so I'd maybe be inclined to choose that one instead.Here's the successful run with the provider flag being forced: https://app.circleci.com/pipelines/github/localstack/localstack/28834/workflows/52d80e8f-6354-4764-b073-4f36f10fc121
Changes
@dfangl changes:
dynamodb/provider.py
<->dynamodb/v2/provider.py
)@bentsku changes:
Limitations
This new implementation does not support
DynamoDB.EnableKinesisStreamingDestination
API action and logic about dispatching event to Kinesis directly yet.TODO
What's left to do: