Skip to content
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

fix(aws-s3-deployment): fix server side encryption parameters #6006

Merged
merged 2 commits into from
Feb 4, 2020
Merged

fix(aws-s3-deployment): fix server side encryption parameters #6006

merged 2 commits into from
Feb 4, 2020

Conversation

mattsains
Copy link
Contributor

fixes #6002

I wasn't able to attach my local copy of the CDK to a package using one to perform an integration test, but I am happy to accept assistance doing this.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@mattsains
Copy link
Contributor Author

In https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md#step-4-commit

  • "Please follow the PR checklist written below", but I couldn't find anything like that in that file.
  • "assign the PR for a review to the "awslabs/aws-cdk" team.", but I could not add such a user from the Reviewers section of the PR UI

@mattsains mattsains requested a review from a team January 28, 2020 23:23
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@skinny85 skinny85 assigned skinny85 and iliapolo and unassigned skinny85 Jan 29, 2020
Copy link
Contributor

@iliapolo iliapolo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @mattsains, PR looks good!

I do have a small note though. Like you pointed out, you changed the key names to match the aws s3 sync command line options as specified here: https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html

Looking at the code, I see we actually have additional keys that don't match the CLI options:

  • website-redirect-location should be website-redirect
  • sse-customer-algorithm should be sse-c-copy-source

How do you feel about piggy backing this PR and issue to also fix those keys?

@@ -239,7 +239,8 @@ export = {
contentLanguage: "en",
storageClass: s3deploy.StorageClass.INTELLIGENT_TIERING,
contentDisposition: "inline",
serverSideEncryption: s3deploy.ServerSideEncryption.AES_256,
serverSideEncryption: s3deploy.ServerSideEncryption.AWS_KMS,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This kind of removes our test for the AES_256 use-case, which we don't want to give up (correct me if i'm missing something here).
Lets just add another test for the AWS_KMS case. Which I see is completely missing from this file.

In general, we always prefer adding tests, rather than extending or changing existing ones. Even if it means duplicating most of the test code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your philosophy might vary, but this is just checking that the code correctly translates the property keys. The actual values of these properties doesn't have any factor on the test. I just changed this to AWS_KMS so I could add an additional property to the assertion. I could have left it as AES_256 and although it doesn't really make sense to specify a KMS key ID along with AES_256, the test would still pass.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another thing to consider is what use case this test is testing: "object metadata can be given" - I haven't eroded this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your right, I didn't notice which exact test this was in. This test simply validates the given metadata: { "A": "1", "b": "2" } is translated into { 'x-amzn-meta-a': '1', 'x-amzn-meta-b': '2' }.

This means your added properties don't belong there (in fact none of the additional properties belong there).

What I would expect to see is an another test, perhaps call it 'props translate to system metadata', that validates the properties are translated to the expected keys. This test can than porbably be modified every time we add a property. Its important also not to mix test-cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry, I don't understand this piece of feedback. It seems like you're asserting that this case is testing the metadata -> UserMetadata mapping. However, there are far more fields in this test for everything else -> SystemMetadata in this test.

Anyway, I'll copy this test case to another test case and remove most of the fields from the original test.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I just realized the props translate to system metadata test im suggesting is in fact just a subset of the object metadata can be given test. Its just confusing because metadata is the name of property as well.

I'm still not liking the removal of that property value because in affect it does erode a test. Imagine for some reason we change this enum value, some test should fail. Currently, it looks like its this one.

Copy link
Contributor

@iliapolo iliapolo Feb 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, now the confusion if out of the way, hopefully.

What i would do is:

  • Leave the current test as is.
  • Add another test that simply validates translation of the missing keys. Why another test? because I do want to use the AWS_KMS value in the new one, but also leave the test for AES_256.

Or whatever combination that gets us to a point we are validating both enum values.

Does that make sense?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a systemic problem with these tests. The following classes have values which are not tested:

  • CacheControl
  • StorageClass

For the purposes of getting this PR approved, I will add tests for the ServerSideEncryption enum

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated this PR with that test.

@iliapolo
Copy link
Contributor

iliapolo commented Feb 3, 2020

@mattsains Wrote:

In https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md#step-4-commit

  • "Please follow the PR checklist written below", but I couldn't find anything like that in that file.
  • "assign the PR for a review to the "awslabs/aws-cdk" team.", but I could not add such a user from the Reviewers section of the PR UI

Regarding the checklist, here it is: https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md#pull-request-checklist

Regarding the team, your'e right, its probably outdated. I'll see that its fixed. Thanks.

@mattsains
Copy link
Contributor Author

I do have a small note though. Like you pointed out, you changed the key names to match the aws s3 sync command line options as specified here: https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html

Looking at the code, I see we actually have additional keys that don't match the CLI options:

* _website-redirect-location_ **should be** _website-redirect_

* _sse-customer-algorithm_ **should be** sse-c-copy-source

How do you feel about piggy backing this PR and issue to also fix those keys?

Will do

@iliapolo
Copy link
Contributor

iliapolo commented Feb 3, 2020

@mattsains Wrote:

I wasn't able to attach my local copy of the CDK to a package using one to perform an integration test, but I am happy to accept assistance doing this.

Not sure what you mean by "attach my local copy...". Have you checked out our integration tests section? https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md#integration-tests?

Also - probably more relevant to your use case, since you actually need to run cdk deploy to test everything works: https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md#running-cli-integration-tests.

Adding this test won't be a blocker for this PR, since i feel pretty confident about the fix and about our ability to maintain it. However, i'd still take a stab at getting a full integration test working as it will really help with future contributions, totally up to you :). I'm ready to help of course.

@mattsains
Copy link
Contributor Author

While trying to fix the customer-algorithm property, I found another bug: #6080

I don't have time to fix that so I just created the above issue.

@iliapolo
Copy link
Contributor

iliapolo commented Feb 3, 2020

While trying to fix the customer-algorithm property, I found another bug: #6080

I don't have time to fix that so I just created the above issue.

Nice, thanks 👍

@mattsains
Copy link
Contributor Author

I updated my branch with the requested changes.

@mergify mergify bot dismissed iliapolo’s stale review February 3, 2020 23:05

Pull request has been modified.

@@ -239,7 +239,8 @@ export = {
contentLanguage: "en",
storageClass: s3deploy.StorageClass.INTELLIGENT_TIERING,
contentDisposition: "inline",
serverSideEncryption: s3deploy.ServerSideEncryption.AES_256,
serverSideEncryption: s3deploy.ServerSideEncryption.AWS_KMS,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your right, I didn't notice which exact test this was in. This test simply validates the given metadata: { "A": "1", "b": "2" } is translated into { 'x-amzn-meta-a': '1', 'x-amzn-meta-b': '2' }.

This means your added properties don't belong there (in fact none of the additional properties belong there).

What I would expect to see is an another test, perhaps call it 'props translate to system metadata', that validates the properties are translated to the expected keys. This test can than porbably be modified every time we add a property. Its important also not to mix test-cases.

@mergify mergify bot dismissed iliapolo’s stale review February 3, 2020 23:29

Pull request has been modified.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

iliapolo
iliapolo previously approved these changes Feb 4, 2020
@mattsains mattsains removed the request for review from a team February 4, 2020 00:02
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify mergify bot dismissed iliapolo’s stale review February 4, 2020 00:25

Pull request has been modified.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Feb 4, 2020

Thank you for contributing! Your pull request is now being automatically merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BucketDeployment: invalid system metadata keys server-side-encryption and ssekms-key-id
4 participants