You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Cloud Platform provides Terraform modules for a variety of common services for use in the Cloud Platform.
Each module currently takes variable inputs to tag resources created by Terraform. However, they are not "standardised" and use different naming conventions (snake_case, kebab-case), and some resources created as part of the modules are not tagged at all.
As resources are typically named with a random ID, it makes identifying untagged services impossible.
Instead of tagging resources separately, we should use the default_tags configuration as part of the provider block in Terraform to simplify this for us.
We should audit the user guide to remove anywhere we ask users to set tags (and do it for them, instead).
Communicate changes
post for #cloud-platform-update
Weeknotes item
Show the Thing/P&A All Hands/User CoP
Announcements channel
We should also communicate changes to teams that use a template to create their namespace files, so they are up to date.
Questions / Assumptions
I have made the assumption that this is only going to apply to the aws provider for now, and that we will retain the default provider (unaliased), the london provider and the ireland provider.
Background
The Cloud Platform provides Terraform modules for a variety of common services for use in the Cloud Platform.
Each module currently takes variable inputs to tag resources created by Terraform. However, they are not "standardised" and use different naming conventions (
snake_case
,kebab-case
), and some resources created as part of the modules are not tagged at all.As resources are typically named with a random ID, it makes identifying untagged services impossible.
Instead of tagging resources separately, we should use the
default_tags
configuration as part of theprovider
block in Terraform to simplify this for us.Modules in scope
Approach
Module by module, likely starting with the least used to the most used, this is the likely approach to take:
aws
providers in namespace-resources-cli-template where the value is the variable from namespace-resources-cli-template's variables.tf (this is so new namespaces will already have it set)namespace-resources-cli-template
Which part of the user docs does this impact
Some users have
GithubTeam
set in their default provider, so we could simplify Accessing the AWS console (read-only).We should audit the user guide to remove anywhere we ask users to set tags (and do it for them, instead).
Communicate changes
We should also communicate changes to teams that use a template to create their namespace files, so they are up to date.
Questions / Assumptions
I have made the assumption that this is only going to apply to the
aws
provider for now, and that we will retain the default provider (unaliased), thelondon
provider and theireland
provider.Definition of done
Reference
How to write good user stories
The text was updated successfully, but these errors were encountered: