-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Sns/v2 verify subscribe operations #13095
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
base: main
Are you sure you want to change the base?
Conversation
e757333
to
405007e
Compare
@@ -0,0 +1,538 @@ | |||
import ipaddress |
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 file is identical to v1 filter.py. I am not sure if this is the correct approach: on the one hand, this might need changing when implementing v2 operations. On the other hand, there are no changes right now, which means any potential change in v1 upstream will have to be copied here, and might get overlooked.
Test Results (amd64) - Integration, Bootstrap 5 files 5 suites 1h 29m 36s ⏱️ Results for commit 555f58d. |
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 1h 0m 23s ⏱️ - 42m 16s Results for commit 555f58d. ± Comparison against base commit 445c32f. This pull request removes 1836 tests.
|
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.
Nice start! I'm not sure I fully understand the logic behind starting with SNS Subscriptions, because we cannot write any tests for it at the moment or validate any of the code of the new provider.
It feels like starting with Topics, at least the CRUD side of it would be the best choice, you could start writing and validating some tests already. As Subscriptions have a hard dependency on topics, it will be easier to first write and validate topics CRUD operations, to then try and validate subscriptions operations.
Implementing all the CRUD operations of Topics should be the first steps, we can keep this PR until then?
I believe that once Topics are migrated, and we start moving over existing Subscription-related code that does not depend on moto, we can see if we need to adapt the v2 store or not, and then decide if we need to copy/paste the current publisher.py
or can use the current one for both with very little adaptation. What do you think?
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.
Same as filter.py
. I don't see a hard dependency on moto here, except the store_delivery_log
function which has a little dependency because of the topic_attributes
dict casing, but it could handle both case without major changes.
The other issue maybe is the store
access: this I can see being an issue, but looking at the current v2 models, they are pretty similar to v1? Except the utility store.get_topic_subscriptions
, but the publisher code could be adapted to not rely on it anymore and internalize the logic instead, for both v1 and v2?
Maybe I am missing something, I think the store access could be a bit problematic but I think it'd be cheaper for us to have publisher.py
be compatible with both instead of full duplication of code that isn't directly relying on moto, what do you think?
PNX-76
Motivation
First step towards creating the new SNS provider. Since subscribe/unsubscribe already almost exclusively lived in LocalStack, this seemed like a good fit. However, subscribe is somewhat coupled with publish, and subscribe tests rely on topics. Implementing topics in LocalStack and porting publish operations are therefore the next steps, so we can also start enabling tests.
Code is moved on a need basis. As a result, publisher.py was ported to a degree, but is for now not really usable. This will be addressed in a follow up PR.
Both
certificate.py
as well as executor.py were not copied but directly referenced. Neither have moto dependencies, and due to their size and function they are unlikely to change during this project.Changes
TODO
What's left to do: