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

swap name and environment? #124

Open
shinenelson opened this issue Oct 27, 2021 · 3 comments
Open

swap name and environment? #124

shinenelson opened this issue Oct 27, 2021 · 3 comments

Comments

@shinenelson
Copy link

It would be nice if we had the environment variable first rather than the name of the module because that way it would be easier to sort resources by environment when we have too many resources.

Yes, I am aware that there are tags, filters, etc; but this change would make the list of resources look neat visually not a huge jungle of names with seemingly no order.

@avanti-joshi
Copy link
Contributor

@shinenelson could you share an example of the output you are seeing? are you referring to swapping the name and environment in the tags or the resource name?

@shinenelson
Copy link
Author

are you referring to swapping the name and environment in the tags or the resource name?

the resource names

currently, the naming preference of the resources provisioned by this module is of the form "${var.name}-${var.environment}" ( or variations with prefixes and suffixes ). I was suggesting to swap these to be "${var.environment}-${var.name}".

Using the environment first would make resources list on the AWS management console easier to visually segregate. For example,

prod-wa-1
prod-wa-2
staging-wa-1
staging-wa-2
staging-wa-3
test-wa-1
test-wa-2
test-wa-3
test-wa-4

would be easier to parse visually, than

wa-1-prod
wa-1-staging
wa-1-test
wa-2-prod
wa-2-staging
wa-2-test
wa-3-staging
wa-3-test
wa-4-test

@rpdelaney rpdelaney self-assigned this Apr 5, 2023
@rpdelaney
Copy link
Contributor

@shinenelson Hey, sorry for the slow comms. This sounds like it would be reasonable in a vacuum, but for users who already have deployed the module it might be a destructive change. What would the migration path look like?

@rpdelaney rpdelaney removed their assignment Jan 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants