Suggestion: Auto prefix names with some stack configuration value

[chrsmith]

Reported on the Community Slack:

Something that would be nice is a stack-wide “name prefix” that gets applied to automatically generated names (e.g. for things like prod- or whatever)

This seems like a common pattern in practice, e.g. having several stacks with the same name but differentiated via suffix. e.g. "website-staging", "website-prod", etc.

One reason for resisting this type of thing in the past, was that anything that goes into the resource's name becomes part of its identity. And so if that "name prefix" were ever to change, then the resource would be considered different.

But between having a richer notion of resource identity (e.g. using a UUID instead of URN) and using a Stack's tags (e.g. the project field in Pulumi.yaml), we should be able to come up with something that makes sense in this area.

[ellismg]

But between having a richer notion of resource identity (e.g. using a UUID instead of URN) and using a Stack's tags (e.g. the project field in Pulumi.yaml), we should be able to come up with something that makes sense in this area.

Is the request about Pulumi's name for the resource (e.g. what is encoded in the URN) or is it about the name of the actual cloud resource created by the provider?

When the prefix changes, what is the expected behavior? Your comment makes it sound like you would not expect the resources to change, but if this name is to apply to the underlying resource managed by the provider, I think we would be forced to schedule a replacement, even if we somehow made the URNs stable?

[joeduffy]

We should consider this idea alongside #1518.

[spion-h4]

Another 👍 from me. Including the stack name would be immensely helpful for debugging, especially on the AWS side.

[barakcoh]

+1

any chance this would find its way into the roadmap? adding these prefixes today is just necessary friction and helper functions that only enforce the prefixing conention