feat(logs): configure custom subscription filter name#26498
feat(logs): configure custom subscription filter name#26498mergify[bot] merged 4 commits intoaws:mainfrom
Conversation
aws-cdk-automation
left a comment
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
| /** | ||
| * The name of the subscription filter. | ||
| */ | ||
| readonly filterName?: string; |
There was a problem hiding this comment.
Thank you for your comment! Sorry, I don't understand your intention. What do you mean need a default? As I described in the below conversation, I think it's better that filterName is optional because this can still let CDK/CFn generate physical id (filter name) automatically when this prop isn't specified.
There was a problem hiding this comment.
For optional properties, we supply a default value in the documentation so our users know what it means when they don't supply anything:
/**
* The name of the subscription filter.
*
* @default - a generated name is created for you
*/
readonly filterName?: string;There was a problem hiding this comment.
Makes sense! I aligned with logGroupName and logStreamName.
aws-cdk/packages/aws-cdk-lib/aws-logs/lib/log-group.ts
Lines 381 to 386 in e53e8dc
aws-cdk/packages/aws-cdk-lib/aws-logs/lib/log-group.ts
Lines 502 to 509 in e53e8dc
| destinationArn: destProps.arn, | ||
| roleArn: destProps.role && destProps.role.roleArn, | ||
| filterPattern: props.filterPattern.logPatternString, | ||
| filterName: this.physicalName, |
There was a problem hiding this comment.
wait, won't this change all subscription filters even if they don't supply props.filterName? Why is there a need to propagate the filterName to physicalName this way
There was a problem hiding this comment.
Thank you for your comment!
won't this change all subscription filters even if they don't supply props.filterName?
In my understanding, if we don't specify filterName prop introduced by this PR, this.physicalName will be undefined and then filterName for L1 CfnSubscriptionFilter construct will be also undefined. As a result, FilterName porperty for AWS::Logs::SubscriptionFilter resource in generted CFn template will be omitted. I already tested with the sample app in my env.
Why is there a need to propagate the filterName to physicalName this way
I align this with the similar constructs such as LogGroup, LogStream or MetricFilter as below.
aws-cdk/packages/aws-cdk-lib/aws-logs/lib/log-group.ts
Lines 466 to 469 in 51b20f9
aws-cdk/packages/aws-cdk-lib/aws-logs/lib/log-stream.ts
Lines 67 to 70 in 9a3399f
aws-cdk/packages/aws-cdk-lib/aws-logs/lib/metric-filter.ts
Lines 25 to 28 in 9a3399f
From CFn perspective, if we specify FilterName property, this is used as physical id. Shouldn't we propagate the filterName to physicalName?
There was a problem hiding this comment.
We can't, because that would be a breaking change for users who don't specify filterName. The behavior that existed before needs to be maintained, unfortunately.
In practice, if we really want to change the behavior we hide it behind a feature flag. But this ins't important enough to go down that route, imo.
There was a problem hiding this comment.
Oh wait you're saying this.physicalName will be undefined if no filterName is given... hmm maybe thats the case but I would be surprised.
There was a problem hiding this comment.
Nevermind, you are right :)
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Currently, we can't set the subscription filter name as a prop for L2 SubscriptionFilter construct. This PR introduces the new prop
filterName. This will let us set a specific name without requiring escape hatches.Closes #26485
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license