-
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(vpc): allow Vpc.fromLookup() to discover asymmetric subnets #4544
Conversation
Thanks so much for taking the time to contribute to the AWS CDK ❤️ We will shortly assign someone to review this pull request and help get it
|
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.
Sweet, thanks Adam!
@@ -1,4 +1,4 @@ | |||
export const VPC_PROVIDER = 'vpc-provider'; | |||
export const VPC_PROVIDER = 'vpc-provider2'; |
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 seems dangerous. It means the CLI cannot possibly recognize both vpc-provider1
and vpc-provider2
requests at the same time, which means the CLI breaks backwards compatibility with old CX-api versions.
How do we make sure that the new CLI will still handle old frameworks?
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.
Damn, you're right. That means we have to have a new provider, just for this case.
Will change.
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.
Here's an interesting question.
We will have 2 very similar providers: the "old" VPC one, and the "new" VPC one that accepts asymmetric subnets. Their code will be quite similar. Should I:
a) have the new provider be completely separate from the old one - they should not share any code (as the old one is there only for backwards compatibility reasons); or
b) should I refactor the old one to have an abstract class, and then have both the old one and the new one inherit from this abstract class, to reduce code duplication?
@rix0rrr what do 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.
Maybe even have a single class and have them do something else based on the input format? Instead of adding a new provider you could also add a version number in the request.
But yes, otherwise let's share code. Maybe the V1 uses the V2, and applies additional restrictions on the output afterwards?
Also, we're going to need to bump the CX version number to tell people that they need to upgrade their CLI to use the new VPC provider (don't forget to add a "version upgrade" code path, which again can do nothing except push up the CX version number 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.
Maybe even have a single class and have them do something else based on the input format? Instead of adding a new provider you could also add a version number in the request.
I like this idea. That's what I did in the newest version. There's a new optional property for the request, returnAsymmetricSubnets
, which Vpc.fromLookup()
now uses, and it triggers the new behavior in the (existing) VPC provider.
Also, we're going to need to bump the CX version number to tell people that they need to upgrade their CLI to use the new VPC provider (don't forget to add a "version upgrade" code path, which again can do nothing except push up the CX version number one).
Can you expand what needs to be done here? I don't think I understood your comment fully. Is it just changing this to 1.15.0
, or is there something else to be done 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.
// (good), but UNLESS YOU ALSO IMPLEMENT 'upgradeAssemblyManifest' you will also |
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.
Done here: https://github.com/aws/aws-cdk/pull/4544/files?file-filters%5B%5D=.ts#diff-eacf6cc8a5af37f2f5e8202fca7d8ec3R67-R70 , I hope I did it correctly.
Make sure that the CLI will continue to be able to load old cloud assemblies. We do this by using the CLI feature that it can directly load Cloud Assemblies through its `--app` argument, hard copying a couple of cloud assemblies into the test set and trying to synth those. In addition to adding a test for loading v0.36.0 assemblies, also add tests for 2 common context provider requests (AZs and VPC), to make sure new CLIs will continue to be able to handle these context lookup requests. Fixes #4475, pre-emptively adds a regression test for #4544.
29a6125
to
4742344
Compare
Updated with comments. As to the question in #4544 (comment) , for this iteration, I kept the two providers completely separate, not sharing any code. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
jd-carroll is adding CIDR lookup to the VPC provider here: #4591. Heads up that depending on which PR lands first, the other one will need to be updated to integrate this change into both VPC providers. |
4742344
to
bf7ca5d
Compare
Updated with the latest comments.
It should be fine. I looked at #4591, and it looks to me like the merge will be relatively straightforward. Feel free to merge that when it's ready, and I'll deal with resolving the conflicts with this PR. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
@skinny85 @rix0rrr - I question how much of my code in #4591 will actually land (the general purpose of my PR has been debunk'd). However, there may be some useful pieces related to #2232. Happy to amend my PR to include only changes related to that or happy to have the changes consumed by this PR. Whatever folks think is best! |
@rix0rrr can you re-review please? Thanks! |
* fix(cli): add Cloud Assembly backwards compat tests Make sure that the CLI will continue to be able to load old cloud assemblies. We do this by using the CLI feature that it can directly load Cloud Assemblies through its `--app` argument, hard copying a couple of cloud assemblies into the test set and trying to synth those. In addition to adding a test for loading v0.36.0 assemblies, also add tests for 2 common context provider requests (AZs and VPC), to make sure new CLIs will continue to be able to handle these context lookup requests. Fixes #4475, pre-emptively adds a regression test for #4544. * Address review comments
bf7ca5d
to
0d5c5c1
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Added the toolkit versioning part. |
Previously, Vpc.fromLookup() required every subnet group to be in the same Availability Zones, and for all subnets in all groups to cover all of those Availability Zones. This loosens this requirement, so that now Vpc.fromLookup() works for VPCs of all shapes. This also add a way to customize which tag of the subnet is considered when grouping subnets into groups when calling fromLookup(). Fixes aws#3407
0d5c5c1
to
97b47bf
Compare
Fixed missing docs. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
@@ -64,6 +64,11 @@ export function upgradeAssemblyManifest(manifest: AssemblyManifest): AssemblyMan | |||
manifest = justUpgradeVersion(manifest, '1.10.0'); | |||
} | |||
|
|||
if (manifest.version === '1.10.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.
Thank you for getting where I was going with this!
(Now that we've done it twice it will be a tradition ;) )
Thank you for contributing! Your pull request is now being automatically merged. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Any projections on when this might be included in a release. The vpc import restriction is preventing us from using CDK in our dev and production environments. I'll have to rebuild some code as CloudFormation if this isn't released soon. We're really excited about the CDK but for now this is a show stopper for us. |
also looking forward for this! |
+1 also looking forward to this! |
@ranman it is already in the new version! Works nice 👍 |
ah strange, just updated thinking this was in it and couldn't get it working
…On Sun, Nov 17, 2019 at 11:13 AM Jonas Kemper ***@***.***> wrote:
@ranman <https://github.com/ranman> it is already in the new version!
Works nice 👍
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4544?email_source=notifications&email_token=AABKYO3WAEJBMY2T7U5VHODQUGJW5A5CNFSM4JBSTKWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEITPGI#issuecomment-554776473>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABKYO52KAB5F34WOF26CSDQUGJW5ANCNFSM4JBSTKWA>
.
|
Previously, Vpc.fromLookup() required every subnet group to be in the same Availability Zones,
and for all subnets in all groups to cover all of those Availability Zones.
This loosens this requirement, so that now Vpc.fromLookup() works for VPCs of all shapes.
This also add a way to customize which tag of the subnet is considered when grouping subnets into groups when calling fromLookup().
Fixes #3407
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license