-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
SESv2 Plan #26796
Comments
Can I ask why you're planning new schemas / resource names? There's not a SESv2 service, or any other difference within the console or resources within AWS. It's purely an SDK / API thing. No one using Terraform will choose between a v1 or v2 resouces. It's just "ses resources". Also, shameless plug but I've done the ground work & email identity work in here: |
Hey @JoshiiSinfield Thank you for your comment. Since the SESv1 and SESv2 are substantially different, the goal is to follow the approach of other services like Also, nice to see your work on the identities 🙌 I think it can become part of |
Thanks @kamilturek . It's not actually that much different? WAFv2 was a whole different set of actual resources. As was apigwv2- a http apigw. Slightly different for ses. As can see from my PR, it's very similar api functions. Not looking forward to having to swap out all ses resources tho tbh. Gonna be a lot of moved resource blocks. Doesn't need to be separate IMO. Apologies, realise I'm not a maintainer or anything so my argument probably doesn't stand. But still wanted to air it! Cheers - would appreciate my work not going redundant. Also shows new resources aren't needed 😂 Cheers |
How would you feel about converting # assigns an existing IP to an existing dedicated IP pool
resource "aws_sesv2_dedicated_ip_assignment" "example" {
ip = "0.0.0.0"
destination_pool_name = aws_sesv2_dedicated_ip_pool.example.pool_name
}
# a single dedicated IP, returns information on warmup percentage, status, etc.
data "aws_sesv2_dedicated_ip" "example" {
ip = "0.0.0.0"
} |
@jar-b That makes sense. Sounds good to me! 👍 |
@kamilturek @jar-b FYI https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-ses-model-provisioning-managing-dedicated-ips/ |
@kamilturek judging by your 27260 shall I close mine then ? |
Thanks for the link @JoshiiSinfield! Sounds like this will require a new Edit: |
Would definitely love to see |
Hey @F21, thanks for your view on this! 🙌 As you mentioned, There is a general tendency of splitting out PUT APIs into their own resources in cases like that. |
I have been testing out the By setting it to resource "aws_sesv2_configuration_set" "my_config_set" {
configuration_set_name = "my-config-set"
suppression_options {
suppressed_reasons = []
}
} This will allow for the case where we want to override the account-level suppression option and disable the suppression list for this configuration set. |
Hey @gmx-git, maybe |
@kamilturek I guess I´m missing the same setting as @gmx-git. The feedback notifications are configured in each verified identity under notifications The configuration sets are an own topic and could be configured as you linked. |
Hey @Scifire. Thank you, I haven't seen that. Looking at this guide, I think it is available only for API v1. I can't find its equivalent in the API v2 specification. I believe it can be achieved by using the configuration set event destination and configuration set assigned to the email identity. There is an SES v1 resource for managing these feedback notifications. |
Hey guys, I've done some research on my own on this topic as well. The APIv1 indeed contained the SetIdentityNotificationTopichttps://docs.aws.amazon.com/ses/latest/APIReference/API_SetIdentityNotificationTopic.html, while there's no correspondence in the APIv2. I've noted a hint while creating a SES identity (see screenshot below). To me it looks like AWS wants to fade out the notifications at the identity level and recommends shifting to notifications on the configuration set level. We can create/set a default configuration set for an SES identity. The default config set will be used by default when sending emails using the SES identity. We don't need to specify it, but the sender should have the rights to use both the SES identity and the default configuration set assigned to it. On my side I'll review my current design and shift the notifications to the default configuration sets. Hope this helps! |
This is a bit off-topic, but not sure where else to write this note/warning... Be very careful when migrating from a SESv1 domain identity to SESv2. Destroying the identity doesn't actually instantly cause it to be removed; it seems to stick around, and blocks you from creating a new identity with the exact same domain name. I managed to work around it by manually messing with the state, but it wasn't something I'd recommend repeating. terraform import aws_sesv2_email_identity.ses_domain YOUR_DOMAIN
terraform state rm aws_ses_domain_identity.ses_domain
terraform state rm aws_ses_domain_dkim.ses_domain_dkim
terraform state rm aws_ses_domain_mail_from.main
terraform apply I don't think Terraform can address this edge case, since it's straight up the AWS API response that's returning confusing information. (i.e. it can sometimes return a 200 when creating a new identity, and then fail right after when you try go get that identity..) |
Is there any reason why the ability to request sandbox removal / production migration from Terraform doesn't seem to be mentioned in any of the plans above? Currently I find this to be a very tedious and manual addition to our otherwise nicely declarative process for turning up in a new region. Specifically I'm looking for a resource that matches the https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutAccountDetails.html API call. |
Hey @mattbnz 👋 - Seems reasonable to me. If you could open a New Resource issue and link back to this one I can add it to the Meta-issue list. Also, to set expectations, implementation of these resources has largely been community driven thus far as this issue is not currently on the maintainer roadmap. |
As core SESv2 resources have been already implemented and it's becoming quite difficult to follow and manage the work through a single GitHub issue, I suggest closing this one and opening new fine-grained issues for remaining resources as needed. I'll keep it open for a few more days in case there are any objections. |
Is |
Hey @jeremyatenovis, the Please have a look at the documentation page. Let me know if you have any questions. |
We are currently using |
Since there isn't a resource |
@raffraffraff I opened a PR with |
What is the difference between SES and SESv2? Which one should I use for a new terraform setup? If I choose V2, am I going to run into issues where I cannot create certain resources since they're not supported yet? Why is this a completely separate resource type instead of Terraform just choosing the best API to use on the backend? |
@nightpool I´d recommend use SESv2. For normal setups everything should work there. I´ve started with SES but reworked it on v2 shortly later cause there are more recent features available. |
I agree with @nightpool and @JoshiiSinfield (way back at the start of this issue) - it's a real shame to have these as new resources IMO, it's confusing. People are going to search resources on the registry for 'ses', then use v1 because it's listed first and v2 not even on the screen. If they do see v2, they'll look in the console for SESv2 and find nothing; search for information for it and find the CLI reference or a blog post, and think why am I having to think about this I'm just using terraform this is an implementation detail, and choose arbitrarily between them (v1 because it looks cleaner and is more established/battle-tested? v2 because it's newer and presumably further from being ever retired?). |
Answering a few comments - it was a concious decision to keep SESv1 and SESv2 as separate services preceded by discussions and agreements. The same thing was done for As announced a few months agowith core SESv2 resources already implemented, I am closing this issue and encourage to open new fine-grained issues for remaining resources as needed. |
Warning This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them. Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed. |
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. |
Community Note
SESv2
This issue contains a plan for SESv2 service implementation. It includes a list of planned resources along with proposed sample schemas. Any feedback is very appreciated.
Not all SESv2 API actions are covered. Attention was primarily paid to main SESv2 resources and the most up-voted SES(v2)-related issues. Although, the remaining SESv2 resources might be also implemented in the future.
This issue also aims to track the progress of SESv2 service implementation.
Table of Contents
aws_sesv2_configuration_setaws_sesv2_configuration_set_event_destinationaws_sesv2_dedicated_ip_poolaws_sesv2_dedicated_ip_assignmentaws_sesv2_contact_listaws_sesv2_email_identityaws_sesv2_email_identity_feedback_attributesaws_sesv2_email_identity_mail_from_attributesResource List
This section lists all service resources with proposed schemas and relevant AWS
API actions. Corresponding data sources (singular and plural) are skipped in the
list but also should be implemented.
Click here to expand
aws_sesv2_configuration_set
Schema
API Actions
aws_sesv2_configuration_set_event_destination
Schema
API Actions
aws_sesv2_dedicated_ip_pool
Schema
API Actions
aws_sesv2_dedicated_ip_assignment
Schema
API Actions
aws_sesv2_contact_list
Schema
API Actions
aws_sesv2_contact
Schema
API Actions
aws_sesv2_custom_verification_email_template
To use this feature, your Amazon SES account has to be out of the sandbox.
Schema
API Actions
aws_sesv2_deliverability_test_report
The test is available after 24 hours. It is unclear how the provider plugin should behave in this case.
Schema
TBC
API Actions
aws_sesv2_email_identity
Schema
API Actions
aws_sesv2_email_identity_policy
Schema
API Actions
aws_sesv2_email_template
Schema
API Actions
aws_sesv2_import_job
Schema
API Actions
aws_sesv2_suppressed_destination
Schema
API Actions
aws_sesv2_account
This is only a data source.
Schema
API Actions
Related
#14320
#10703
#17570
#21129
The text was updated successfully, but these errors were encountered: