Closed chrishanline closed 1 year ago
@mnapoli or @fredericbarthelet any feedback or thoughts on merging this in?
Hi @chrishanline, thanks for proposing a PR for this feature !
We try to provide as simple configurations as possible in Lift, to avoid multiplication of configuration options, such as what you can find in the Serverless Framework current state.
With this in mind, and aware that everyone will have at some point specific requirements for its stack, we developed 2 features :
With extensions, you can manually modify generated Cloudformation to match your use case. In this particular instance, the following code snippet will produce the expected behavior
constructs:
my-queue:
# ...
alarm: dummy@dummy.com
extensions:
alarm:
Properties:
AlarmActions: ["arn:aws:sns:us-east-1:123456789012:alarm-alerts"]
You can find out more about available extensions for the queue construct here.
The downside is you'll still have a SNS topic and subscription being provisioned by Lift without actually being used.
You can eject from Lift at anytime to regain control over the behavior of a single construct when your use case diverges too much from Lift original intent. You can find out more about ejecting in the corresponding documentation here
hi @fredericbarthelet, thanks for the feedback.
when trying the extension, I was unsuccessful. I think I am running into this issue: https://github.com/getlift/lift/issues/265
when I do an eject and look at the cloudformation generated, the AlarmActions
ends up on the Queue
properties, not the alarm.
serverless.yml
constructs:
print:
type: queue
fifo: true
maxRetries: 2
alarm: dummy@alarm.com
extensions:
alarm:
Properties:
AlarmActions: ["arn:aws:sns:us-east-1:123456789012:alarm-alerts"]
cloudformation from eject
printDlq09F2B389:
Type: 'AWS::SQS::Queue'
Properties:
FifoQueue: true
MessageRetentionPeriod: 1209600
QueueName: paperwork-printing-dev-print-dlq.fifo
AlarmActions:
- 'arn:aws:sns:us-east-1:123456789012:alarm-alerts'
UpdateReplacePolicy: Delete
DeletionPolicy: Delete
Indeed, would you be up to do a PR for #265 to solve this issue :) ? It should be a matter of replacing the duplicate typo by a reference to the provisioned alarm
Hey @chrishanline, #265 is now fixed. I included an exemple of what you're trying to achieve in the form of a unit test. https://github.com/getlift/lift/blob/5ff580efe8f126eb8a6fa57082b8229f2467c0cb/test/unit/queues.test.ts#L624-L646 This should allow you to specify your own SNS topic as destination for the alarm.
I'm closing this PR in the meantime, please feel free to continue the conversation on #277 if you're still needing additional configuration options for this feature.
Thanks again for your time improving Lift :)
References issue #277
We have existing alerting looking for
Alarm
andOK
message posted to a specific SNS topic.This change allows you to specify an existing SNS topic ARN for
alarm
on the DLQ SQS queue alarm construct. When an ARN that begins witharn:aws:sns:
is present, that topic is used as anAlarmAction
andOKAction
instead of creating a new topic and email subscription.No changes are made if an email address is specified for
alarm
.Additionally adds checking for a bare-minimum of an ARN prefix or
@
inalarm
and throwing an exception if neither is present.