-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
aws_ecs.AsgCapacityProvider: CDK should be smart enough to auto-name ASG capacity provider something valid if stack name starts with illegal keyword #29151
Comments
I believe this also happens for log groups? The only reason I came upon this issue was because I was working on another issue related to CloudFormation, so I made an example stack to show the behavior to an AWS employee. https://github.com/JellyKid/aws-cloudformation-bug The problem is that the CDK doesn't give you a clean way to rename the stack/project. So if you've already spent a bunch of time building something, it's going to be a major pain to try and rename everything. Shouldn't the CDK be smart enough to know what the naming requirements are for each product? |
@JellyKid The CDK does catch erroneously-named capacity providers, per this PR, before the stack gets deployed. You can also not specify the name and the CDK will generate a name. It is not typical of the CDK to change the name of something when you've specified a different name in your code. Hope this helps. |
it would be tested if the name is provided otherwise auto generated by CFN, which would violate if your stack name is having those prefixes. You can work it around like this export class DummyStack extends Stack {
constructor(scope: Construct, id: string, props: StackProps) {
super(scope, id, props);
new ecs.AsgCapacityProvider(this, 'Provider', {
capacityProviderName: this.getProviderName(),
autoScalingGroup: new AutoScalingGroup(this, 'ASG', {
vpc: getDefaultVpc(this),
machineImage: ec2.MachineImage.latestAmazonLinux2023(),
instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.LARGE),
})
})
}
private getProviderName(): string | undefined {
if (!(/^(?!aws|ecs|fargate).+/gm.test(Stack.of(this).stackName))) {
return `cp-${Names.uniqueResourceName(this, { allowedSpecialCharacters: '-', maxLength: 24 })}`
} else {
return undefined
}
}
} And I agree we should have a PR for it. |
@pahud ill do a PR for this |
@msambol 👍 Thank you! |
|
Describe the bug
If your stack name begins with "aws", "ecs", or "fargate", you will receive the following error when creating an ASG capacity provider if you don't specify a capacity provider name.
"Invalid request provided: CreateCapacityProvider error: The specified capacity provider name is invalid. Up to 255 characters are allowed, including letters (
upper and lowercase), numbers, underscores, and hyphens. The name cannot be prefixed with "aws", "ecs", or "fargate". Specify a valid name and try again."
Expected Behavior
I expected the ASG capacity provider to be created without issue no matter what the stack name is.
Current Behavior
I described it pretty well above, but if you have any specific questions. I can't think of anything more relevant that would apply here.
Reproduction Steps
Init a new stack with the CDK in a directory that starts with "aws-"
Create an ASG capacity provider, but don't specify the "capacityProviderName" property so the CDK will autogenerate a name for you
Deploy it
Possible Solution
Maybe don't let a project be initialized with illegal keywords. You could also do a simple regex check when creating the ASG capacity provider to see if the autogenerated name contains those illegal keywords and either remove them or add some other word that is valid.
Additional Information/Context
If we are going to ban the words aws across the board then the CDK should specify that so a linter can catch things like that.
CDK CLI Version
2.128.0 (build d995261)
Framework Version
No response
Node.js Version
v20.10.0
OS
Linux fedora 6.7.4-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 5 22:21:14 UTC 2024 x86_64 GNU/Linux
Language
TypeScript
Language Version
No response
Other information
No response
The text was updated successfully, but these errors were encountered: