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

feat(ecs): ECS optimized Windows images #3376

Merged
merged 15 commits into from
Jul 25, 2019
Merged

Conversation

nmussy
Copy link
Contributor

@nmussy nmussy commented Jul 22, 2019

  • deprecate EcsOptimizedAmi for EcsOptimizedImage
  • constructor(props) replaced by strongly typed static methods
  • Windows AMI support
  • deprecate EcsOptimizedAmi, EcsOptimizedAmiProps
  • will require changes on v2 shipment #3398

Fixes #2574


Please read the contribution guidelines and follow the pull-request checklist.

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

@nmussy nmussy requested a review from a team as a code owner July 22, 2019 09:34
*
* @default none, uses Linux generation
*/
readonly windowsVersion?: WindowsOptimizedVersion;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ideally, the generation and windowsVersion properties would be merged, but I didn't think it was worth the refactoring and breaking change.

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we can @deprecate generation in favor of amazonLinuxGeneration (still support generation for backwards compat and in the next MV we will remove)

Copy link
Contributor

Choose a reason for hiding this comment

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

Thoughts? Maybe in a subsequent PR? At least update #3398 with this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, I didn't see your previous comment. I can add it to this PR

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Shouldn't we just replace it with an image union construct, to have the definition enforce the mutual exclusion?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes!

Copy link
Contributor

Choose a reason for hiding this comment

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

So what's up with this? Didn't we say this is gone?

Copy link
Contributor

@eladb eladb left a comment

Choose a reason for hiding this comment

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

Looks good.

} else {
this.generation = props.generation;
}
} else if (props && props.windowsVersion) {
if (this.hwType !== AmiHardwareType.STANDARD) {
throw new Error('Windows Server does not support special hardware type. Use Amazon Linux 2 instead');
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove "use Amazon Linux 2 instead". I am assuming that if a user explicitly specified they wanted Windows, they should probably just not specify the HW type and not use Linux instead... :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

});

// THEN
expect(stack).to(haveResource("AWS::AutoScaling::LaunchConfiguration", {
Copy link
Contributor

Choose a reason for hiding this comment

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

You should add an expectation on the parameter with the desired SSM path...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, I don't understand your comment. I reused the existing HW AMI Type test:

expect(stack).to(haveResource("AWS::AutoScaling::LaunchConfiguration", {
ImageId: {
Ref: "SsmParameterValueawsserviceecsoptimizedamiamazonlinux2gpurecommendedimageidC96584B6F00A464EAD1953AFF4B05118Parameter"
}
}));

Copy link
Contributor

Choose a reason for hiding this comment

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

This just shows the ImageId is a reference to a synthesized CloudFormation parameter that is added to your template. You should write your expectation against the default value of the parameter which will contain the SSM parameter name that you want.

What I usually do is expect(stack).toMatch({}) and then I can see which parts of the stack to assert against.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good call, I was missing an assignation, thanks.

I have an issue with the matching now. I tried changing the MatchStyle, but it doesn't seem to detect when I purposefully change the Default matched value.

Should I use an integration test instead, to match the whole stack?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I think there's a bug in the matcher (raise an issue?). What you could do in the meantime is as follows;

// you'll need an "App"
const app = new App();
const stack = new Stack(app, 'test');

// ...

// then
const assembly = app.synth();
const template = assembly.getStack(stack.stackName).template;
test.deepEqual(template.Parameters, { /* expectation here */ });

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alright, thanks a lot. Should I also update the existing Linux AMI test?

expect(stack).to(haveResource("AWS::AutoScaling::LaunchConfiguration", {
ImageId: {
Ref: "SsmParameterValueawsserviceecsoptimizedamiamazonlinux2gpurecommendedimageidC96584B6F00A464EAD1953AFF4B05118Parameter"
}
}));

If so, should I do it in another PR?

Copy link
Contributor

Choose a reason for hiding this comment

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

Feel free to add to this PR

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. Thanks again for the help!

*
* @default none, uses Linux generation
*/
readonly windowsVersion?: WindowsOptimizedVersion;
Copy link
Contributor

Choose a reason for hiding this comment

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

Thoughts? Maybe in a subsequent PR? At least update #3398 with this.

packages/@aws-cdk/aws-ecs/lib/cluster.ts Outdated Show resolved Hide resolved
*
* @default none, uses Linux generation
*/
readonly windowsVersion?: WindowsOptimizedVersion;
Copy link
Contributor

Choose a reason for hiding this comment

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

So what's up with this? Didn't we say this is gone?

* EcsOptimizedAmiStatic -> EcsOptimizedImage
@nmussy nmussy changed the title feat(ecs): support windows images feat(ecs): EcsOptimizedImage static construct Jul 25, 2019
@eladb eladb changed the title feat(ecs): EcsOptimizedImage static construct feat(ecs): support ECS optimized Windows images Jul 25, 2019
@eladb eladb changed the title feat(ecs): support ECS optimized Windows images feat(ecs): ECS optimized Windows images Jul 25, 2019
@eladb eladb merged commit 6c0bf4a into aws:master Jul 25, 2019
@nmussy nmussy deleted the feat-windows-ecs branch July 25, 2019 19:34
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.

Support windows containers
2 participants