-
Notifications
You must be signed in to change notification settings - Fork 4k
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(pipes): add LogDestination implementation #31672
Conversation
@@ -1,5 +1,9 @@ | |||
// eslint-disable-next-line import/no-extraneous-dependencies | |||
import { IDeliveryStream } from '@aws-cdk/aws-kinesisfirehose-alpha'; |
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.
@paulhcsun I saw you working on this module. Can I use this here??
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.
Hi @msambol, sorry I missed this. There were a couple of breaking changes added to the aws-kinesisfirehose-alpha
module recently right before we moved it to Developer Preview. From a quick look I think it's fine in this use case but I'd recommend taking a look at the release notes to see if anyof the recent changes conflicts with the usage of the DeliveryStream in this PR.
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.
Thanks, @paulhcsun! looks good from my view too. I'm just importing IDeliveryStream
here.
This PR has been in the BUILD FAILING state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week. |
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.
Had a quick look, I might have missed some things
}, | ||
"dependencies": {}, | ||
"peerDependencies": { | ||
"aws-cdk-lib": "^0.0.0", | ||
"constructs": "^10.0.0" | ||
"constructs": "^10.0.0", | ||
"@aws-cdk/aws-kinesisfirehose-alpha": "0.0.0" |
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.
Is the peer dependency required here?
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 so.. because I am importing IDeliveryStream
in logs.ts
:
import { IDeliveryStream } from '@aws-cdk/aws-kinesisfirehose-alpha';
When I do npx lerna run build --scope=@aws-cdk/aws-pipes-alpha
I get an error if I don't have it.
parameters: { | ||
s3LogDestination: { | ||
bucketName: this.parameters.bucket.bucketName, | ||
bucketOwner: this.parameters.bucketOwner || this.parameters.bucket.env.account, |
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.
@nmussy I had to add this default otherwise I got the following:
Failed resources:
aws-cdk-pipes | 10:24:59 AM | UPDATE_FAILED | AWS::Pipes::Pipe | Pipe (PipeXXX) Resource handler returned message: "[object has missing required properties (["BucketOwner"])] (Service: Pipes, Status Code: 400, Request ID: xxx)" (RequestToken: xxx, HandlerErrorCode: InvalidRequest)
Add this to the doc: @default - account ID derived from 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.
Shouldn't be an issue given how the env
prop is built (see below), but just for safety could you add a bucket import in a unit test?
aws-cdk/packages/aws-cdk-lib/core/lib/resource.ts
Lines 171 to 174 in 5cb47da
this.env = { | |
account: props.account ?? parsedArn?.account ?? this.stack.account, | |
region: props.region ?? parsedArn?.region ?? this.stack.region, | |
}; |
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.
Great shout. I added a unit test here: https://github.com/aws/aws-cdk/pull/31672/files#diff-7ee5baaeb407c0ce0a9d967e0d0ef9bd3523ede78b48d34fea55b538b030e739R564.
@paulhcsun Do you have time for a review here this week? |
@Leo10Gama When you have time could you look here? This will be nice to round out the rest of |
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.
Thanks for the contribution! Seems like great work, I left a few comments on what could probably be improved and fine-tuned. It does seem like the original vision for this library was for the log destinations to be in their own folder like the targets and sources, but I'll double check with the CDK team to confirm if that's the route we want to go, since it may lead to more confusion later down the line.
|
||
> Currently no implementation exist for any of the supported enrichments. The following example shows how an implementation can look like. The actual implementation is not part of this package and will be in a separate one. |
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.
It seems like the expected approach for this module is to have a new folder for the log destinations, likely akin to how we have aws-pipes-sources-alpha
and aws-pipes-targets-alpha
. We should probably follow this guideline, but I'll bring it up with the CDK team to confirm and get back to you, since it may add more confusion splitting one module into so many different parts.
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.
Yeah, I'd prefer to leave these in aws-pipes
but open to feedback from the team.
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.
It seems like there is an argument to be made about having this be in the aws-pipes-alpha
module, but there isn't really much extra cost having a separate aws-pipes-log-destinations-alpha
folder, or something of that nature. One of the main reasons these are split the way they are is to prevent the risk of circular dependencies, and I'm not sure how big of a risk that could be in this case.
I think we could leave things as is, but I would lean more towards making a separate module for log destinations, and in the future before graduating this module, see if we can refactor things and consolidate everything into one. Thoughts?
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'd prefer to leave them here. Logging configuration is tied to a pipe, so I think it makes sense. But will of course default to you and the team.
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.
Also, kinesis is now in dev preview which I think was the concern with circular dependency?
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.
Not sure how dev preview might be a circular dependency concern; if anything I think the risk with that is, when it's out of dev preview and into GA, the import will need to be updated, but that's expected. It more so applies to the module as a whole, but we can keep the log destination resources here, and investigate refactoring at a later time.
* @see https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-pipes-pipe-s3logdestination.html#cfn-pipes-pipe-s3logdestination-bucketname | ||
*/ | ||
readonly bucket: IBucket; |
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.
The documentation you linked here shows that the bucket property isn't required, but we're mandating it here. I'm curious as to why that may be the case.
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.
It's not required to create a pipe but it is required if you want to create an S3LogDestination
. IMO the docs should be updated.
Pull request has been modified.
Update with your feedback – thanks! |
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.
Thanks for the timely response! Just a few more nits and minor comments on my end
Pull request has been modified.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #31672 +/- ##
=======================================
Coverage 77.46% 77.46%
=======================================
Files 105 105
Lines 7168 7168
Branches 1314 1314
=======================================
Hits 5553 5553
Misses 1433 1433
Partials 182 182
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Fixed! Thanks. |
@Leo10Gama any further feedback on this one? Could we get this in too 😄 |
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.
Thanks for your patience! Just one minor comment about the S3OutputFormat
default value.
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.
Thanks for the quick response, changes look good to me!
@Mergifyio update |
✅ Branch has been successfully updated |
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). |
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). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Comments on closed issues and PRs are hard for our team to see. |
Closes #31671.