-
Notifications
You must be signed in to change notification settings - Fork 247
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
feat(aws-kinesisfirehose-s3): added custom logging bucket props to kinesisfirehose-s3 #478
Conversation
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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.
Stopped after index.ts because I requested moving a bunch of code to s3-helper.ts
source/patterns/@aws-solutions-constructs/aws-kinesisfirehose-s3/README.md
Outdated
Show resolved
Hide resolved
source/patterns/@aws-solutions-constructs/aws-kinesisfirehose-s3/lib/index.ts
Show resolved
Hide resolved
source/patterns/@aws-solutions-constructs/aws-kinesisfirehose-s3/lib/index.ts
Show resolved
Hide resolved
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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.
I spent a lot of time looking at s3-bucket-helper.ts. I made many comments/requests because the changes were pretty major and the module is fundamental - but in general I like that the changes seemed to make it simpler to follow.
@@ -24,6 +24,9 @@ stack.templateOptions.description = 'Integration Test for aws-cdk-apl-kinesisfir | |||
new KinesisFirehoseToS3(stack, 'test-firehose-s3', { | |||
bucketProps: { | |||
removalPolicy: RemovalPolicy.DESTROY, | |||
}, | |||
loggingBucketProps: { | |||
removalPolicy: RemovalPolicy.DESTROY |
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.
Does this fully remove the bucket? Or do we also need autoDeleteObjects: true?
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.
Fully removes the bucket
source/patterns/@aws-solutions-constructs/core/lib/input-validation.ts
Outdated
Show resolved
Hide resolved
bucketprops = DefaultS3Props(); | ||
} | ||
} else if (logS3AccessLogs !== false) { | ||
if (logS3AccessLogs !== false && !userBucketProps?.serverAccessLogsBucket) { |
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.
!userBucketProps?.serverAccessLogsBucket
This is really hard to decipher. I've had to write a couple of these as well - I usually go to the TypesScript scratch pad and try to test all the different possibilities. But the combination of not the whole expression, the optional operator on userBucketProps and serverAccessLogsBucket defaulting to true makes it a mess of double negatives. And the first part, logS3AccessLogs !== false
has the knowledge that the value defaults to true hidden in it. I never liked my results.
What do you think of
// Put these in core\utils.ts
export function EvaluateOptionalBoolean(value: boolean | undefined, defaultValue: boolean) : boolean {
return value ?? defaultValue;
}
export function ValueExists(value | any) : boolean {
return (value === undefined) ? false : true;
}
// Then this line becomes
if (EvaluateOptionalBoolean(logS3AccessLogs, true) &&
!ValueExists(userBucketProps?.serverAccessLogsBucket)) {
The fact that the default for the attribute is true is now explicit in the code. The second condition now has a function name that explicitly describes what we're checking. At this point I'm not insisting on a change - like to hear what you think first.
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.
I think that creating the additional functions is unnecessary as it performs the same functionality. I believe we should take advantage of the built in javascript operators for its purpose. I have changed !userBucketProps?.serverAccessLogsBucket
to !(props.bucketProps?.serverAccessLogsBucket)
for clarity. I left it as props.logS3AccessLogs !== false
because the real default is undefined allowing it to pass for use cases when it is undefined or true. I actually find the additional functions harder to decipher than the ones I provided. Will also add a comment above the line. Let me know what 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.
OK - but the default is no undefined. If it is undefined we use the default value, which is true.
} else if (s3BucketProps?.removalPolicy) { // Deletes logging bucket only if it is empty | ||
loggingBucketProps = overrideProps(DefaultS3Props(), { removalPolicy: s3BucketProps.removalPolicy }); | ||
} else { // Default S3 bucket props | ||
} else if (userBucketProps?.removalPolicy) { |
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 would be an argument against ArgumentExists(), because:
- If we implemented ArgumentExists(), we would want to use it here.
- This is such a common Typescript expression that it's clear without any abstraction behind a function.
Makes me think that ArgumentExists() is overkill and I should just suck it up WRT to the ! operator in line 152. I still think a EvaluatateOptionalBoolean where we explicitly declare a default merits consideration.
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.
I agree, I believe it is overkill as it is a common Typescript expression
source/patterns/@aws-solutions-constructs/core/lib/s3-bucket-helper.ts
Outdated
Show resolved
Hide resolved
source/patterns/@aws-solutions-constructs/core/lib/s3-bucket-helper.ts
Outdated
Show resolved
Hide resolved
bucketprops = DefaultS3Props(); | ||
} | ||
} else if (logS3AccessLogs !== false) { | ||
if (logS3AccessLogs !== false && !userBucketProps?.serverAccessLogsBucket) { |
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.
Remind me - do we throw an error earlier if they set logS3AccessLogs to false but still send a serverAccessLogsBucket or logBucketProps?
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.
Yes, we throw an error through input-validation.ts
@@ -445,3 +445,53 @@ test('Test fail Log Bucket check', () => { | |||
// Assertion | |||
expect(app).toThrowError('Error - Either provide existingLoggingBucketObj or loggingBucketProps, but not both.\n'); | |||
}); | |||
|
|||
test('Test fail false logS3Accesslogs and loggingBucketProps check', () => { |
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.
I think this and line 431 answer my earlier "Remind me..." comment?
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.
Correct
source/patterns/@aws-solutions-constructs/core/lib/s3-bucket-helper.ts
Outdated
Show resolved
Hide resolved
@@ -42,7 +42,7 @@ export interface BuildS3BucketProps { | |||
* | |||
* @default - true | |||
*/ | |||
readonly logS3AccessLogs?: boolean; | |||
readonly logS3AccessLogs?: boolean; | |||
} | |||
|
|||
export function buildS3Bucket(scope: Construct, props: BuildS3BucketProps, bucketId?: string): [s3.Bucket, s3.Bucket?] { |
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.
We made some fundamental changes to this module and it is fundamental to a lot of constructs. If possible we should get to 100% statement and branch coverage:
@aws-solutions-constructs/core: s3-bucket-helper.ts | 98.07 | 96.66 | 100 | 98.07 | 148
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Issue #474 , if available:
Description of changes:
-Added custom logging bucket props to kinesisfirehose-s3
-Created unit and integ test for custom logging bucket
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
fixes #474
issue #485