Easiest way to implement human-friendly, unique resource names

[marcusjv-po]

If a resource name for a Tropo object isn't provided in a blueprint, per the Stacker documentation:

"child resources of your stacks will, by default, use a portion of your stack name in the auto-generated resource names, the first characters of your fully-qualified stack name potentially convey valuable information to someone glancing at resource names".

I'd like to implement cleaner human-friendly resource names that somehow incorporate the namespace/environment. This is intended to enhance readability in the AWS console.

The issue: If multiple stacks (stage, prod) are configured inside the same account, and you wish to control the naming of resources in both, you must incorporate your own unique naming scheme inside your blueprints to avoid collisions:

<Physical-ID-Name> already exists in...

This implies passing unique resource names as Variables, or somehow accessing the namespace or environment from within the Blueprint, and appending it to a 'base' name.

Thoughts?

[phobologic]

Hey @marcusjv-po - so this isn't really a stacker thing so much as a troposphere, and more importantly, an underlying cloudformation thing. Lets take a simple example - an s3 bucket. You can, if you want, control the bucket name by providing BucketName (almost all resources with "names" have something similar): https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html#cfn-s3-bucket-name

However, Cloudformation has a big gotcha with human named resources (you'll notice a link to this page from every resource with a Name property, btw):

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-name.html

Basically, if any update requires a replacement (and many do for good reason) you can't update that resource because Cloudformation can't create a new name for you, and the way cloudformation replaces something is:

1. create new resource with new name
2. delete old resource

Since names are unique, it can't create #1 if you provide a static name.

That said, for the most part, I've found this isn't a bad thing. Many resources actually have a tag called Name, and if you set that it's almost always shown in the console. In the end, Cloudformation, and stacker by extension, tends to take the "treat your resources like cattle not pets" approach, which is surprisingly pretty easy to get used to in the long run.

Hope that helps! let me know if you have any other questions!

(PS: BTW, because of the trickiness with names, I tend to reject open source blueprints that allow setting them in stacker_blueprints - it's too easy to shoot yourself in the foot, and not realize it till some point in the future, so I avoid them in the open source provided examples).

[marcusjv-po]

@phobologic:

Thanks much for the quick reply!

I'm aware that this is a Tropo/CF thing (and was curious why each resource name requires a unique attribute; i.e. 'DatabaseName' and 'BucketName' as opposed to just 'Name').

However, my thought was to somehow extract the environment name or namespace from the stacker context within a blueprint, and use string formatting to apply that to the resource name.

Given the CF limitation you described via the above links, it obviously isn't practical to use the Physical ID as a human-friendly identifier, so we you can just close this issue (which I see you've already done).

[phobologic]

@marcusjv-po so you can always use envronments in your BucketName variable, for example. If you have namespace and environment set in your environment file, you could name it something like:

BucketName: ${namespace}-${environment}-mybucket

You'll still run into the Name Type issue linked above though, so be careful :)

[marcusjv-po]

I've used var interpolation in the config before (much like you describe), but am now discontinuing this pattern after raising this issue. It requires me to add variables to blueprints etc and it isn't worth it, especially considering your explanation of the CF limitation and the pets/cattle reasoning behind it.

On Fri, Aug 24, 2018, 12:58 PM Michael Barrett notifications@github.com wrote:

@marcusjv-po https://github.com/marcusjv-po so you can always use envronments in your BucketName variable, for example. If you have namespace and environment set in your environment file, you could name it something like:

BucketName: ${namespace}-${environment}-mybucket

You'll still run into the Name Type issue linked above though, so be careful :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cloudtools/stacker/issues/647#issuecomment-415866620, or mute the thread https://github.com/notifications/unsubscribe-auth/AgwszfI-8Bbdg8FS2EnZtvfSRcJ-203Gks5uUFrqgaJpZM4WL4U5 .

[phobologic]

Cool - yeah, I think you'll find that the cattle/pets thing becomes a lot easier as time goes on, and the benefits of it are pretty great in the long run. Let me know if you have any other questions!