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

Enhancement: Expose "Subscription Filter Policy" for AWS SNS Topic Subscriptions #2916

Closed
hashibot opened this issue Jan 10, 2018 · 4 comments
Labels
enhancement Requests to existing resources that expand the functionality or scope. service/sns Issues and PRs that pertain to the sns service.
Milestone

Comments

@hashibot
Copy link

This issue was originally opened by @rbwestmoreland as hashicorp/terraform#17072. It was migrated here as a result of the provider split. The original body of the issue is below.


Enhancement

  • Provider: aws
  • Resource: aws_sns_topic_subscription

Please expose the "Subscription Filter Policy" feature for the aws_sns_topic_subscription resource.

A subscription filter policy is a simple JSON object that enables your subscriber to receive only the subset of messages it’s actually interested in, as opposed to receiving every single message published to the topic.

When a message is published to the topic, Amazon SNS will attempt to match the incoming message attributes to the subscription attribute that defines a filter policy. If they match, Amazon SNS will then deliver the message to the corresponding subscriber.

References

@hashibot hashibot added the enhancement Requests to existing resources that expand the functionality or scope. label Jan 10, 2018
@radeksimko radeksimko added the service/sns Issues and PRs that pertain to the sns service. label Jan 28, 2018
@ddcprg
Copy link
Contributor

ddcprg commented Feb 5, 2018

Anyone working on this one? We are interested in this feature and I'll be glad to look at it if no one else is

@ddcprg
Copy link
Contributor

ddcprg commented Feb 5, 2018

I've scanned through the sns_topic_subscription code quickly. For some reason the subscription attributes have been implemented as independent attributes (actually only the RawMessageDelivery has been exposed.) This limits the addition of new subscription attributes easily so I was wondering whether this is general guideline or whether was just a design decision for this specific resource (?)

@bflad
Copy link
Contributor

bflad commented Feb 6, 2018

Hi folks, this issue is a duplicate of #2554, so closing this one in preference of the earlier issue to consolidate discussion and any effort. You will be happy to know there is an open PR for implementing this in #2806, which is almost ready to 🚢 !

For some reason the subscription attributes have been implemented as independent attributes (actually only the RawMessageDelivery has been exposed.) This limits the addition of new subscription attributes easily so I was wondering whether this is general guideline or whether was just a design decision for this specific resource (?)

@ddcprg AWS implements each of their service APIs differently. In this case, the original implementation decision a few years ago has some some pros (additional validation we can perform) and cons (we need to specifically implement each attribute), but this likely will not change anytime in the near future. Architecturally speaking, I do not think we have a stance or guideline whether to map 1:1 with Terraform attributes or not, although in a general sense we would probably lean towards with the mapping as the plan-time validation provides some great benefits which potentially outweigh being slightly behind enhancements. TL;DR Most resources are implemented using what should give the best user experience with their respective service API.

@ghost
Copy link

ghost commented Apr 8, 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 and limited conversation to collaborators Apr 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement Requests to existing resources that expand the functionality or scope. service/sns Issues and PRs that pertain to the sns service.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants