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

How the CDK manage names and logical ids is doing a lot of harm #10796

Closed
olivier-schmitt opened this issue Oct 9, 2020 · 2 comments
Closed
Assignees
Labels
@aws-cdk/core Related to core CDK functionality closed-for-staleness This issue was automatically closed because it hadn't received any attention in a while. guidance Question that needs advice or information. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days.

Comments

@olivier-schmitt
Copy link

olivier-schmitt commented Oct 9, 2020

❓ General Issue

Hi Folks,

I found the CDK extremely powerful but the way it manages names and logical ids by default is doing a lot of harm to this very promising development kit.

CFN stacks and all the medata in them (logical names, names,...) build an information system which is constantly used by humans.

On my side, I tend to look a lot to CFN stacks to understand the scope of ressources a service is related to.

It's also a single point of truth to find various resources and get their coordinates in order to perform checks or understand behaviours.

To me, I would say the CDK default behaviour is harming the ability to exploit this information system a lot.

The CDK is supposed to help us and it does but such a framework is not supposed to obfuscate information.

I understand the conflict thing but to me this is not up to the CDK to replace best practices and common sense in relation to naming conventions and how developpers want their resources to be named.

Plus, by default, some construct associated to the default naming policy tend to break the AWS console UI which is quite bad.

As an example, check the following screenshot:

image

It breaks consistently the UX in the cloudformation UI, the names are so long that the first column takes a lot of space and then the 2nd too. Finally the status of the resource is hard to catch rapidly. It's barely useable !

image

What is purpose of such default naming exactly ?

Hopefully some CDK ressources seem to support custome names but of for instance I did not find a way to have a clear name for the autoscaling scaling policy with a ridiculus long name "SupportBenchWorkerDevWorkerQueueServiceQueueProcessingFargateServiceTaskCountTargetCpuScaling124CEB17" which breaks the UI.

Additonnally, this naming thing is orthogonal to AWS SDK and API.

For instance when using boto3 or CFN you have most of the time to provide the right naming which forces you to build a consistent and well scoped naming space which is BTW part of any development practice in every language.

Could you imagine a language which will prevent you, by default, to name you own resources and then to constantly forces you to make a translation between your mental model and the language model, because developers would be to dumb to avoid naming conflict ?

And last but not least, to migrate existing stacks which had been carefully built with all the naming convention best practices is probably a very tedious task to do if fully possible.

It's too bad to have built such a powerful framework and to have spoiled it with such naming behaviour.

I hope it will change because I would like to fully embrace the CDK approach but this naming thing is almost a no go and a pain. I don't think it has to have to be that way.

Best.

Other information

@olivier-schmitt olivier-schmitt added guidance Question that needs advice or information. needs-triage This issue or PR still needs to be triaged. labels Oct 9, 2020
@NetaNir
Copy link
Contributor

NetaNir commented Oct 12, 2020

See discussion in several issues: #1424, aws/aws-cdk-rfcs#162 - note the renameLogicalId suggestion.

@SomayaB SomayaB added @aws-cdk/core Related to core CDK functionality and removed needs-triage This issue or PR still needs to be triaged. labels Oct 12, 2020
@rix0rrr rix0rrr added the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Oct 19, 2020
@github-actions
Copy link

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

@github-actions github-actions bot added closing-soon This issue will automatically close in 4 days unless further comments are made. closed-for-staleness This issue was automatically closed because it hadn't received any attention in a while. and removed closing-soon This issue will automatically close in 4 days unless further comments are made. labels Oct 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/core Related to core CDK functionality closed-for-staleness This issue was automatically closed because it hadn't received any attention in a while. guidance Question that needs advice or information. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days.
Projects
None yet
Development

No branches or pull requests

4 participants