#cloudposse (2024-06)

I found my answers by looking at the terraform-null-label documentation and discovered the naming convention

Fixed by setting the proper ID elements

Yep!

You nailed it.

We often use attributes for this.

since I’m new to this I have a question, how would “different products” be represented with the pieces I see? Let’s say I have “company” that needs to deploy “thing1” and “thing2” in a single organization/under a single account. Let’s say that thing2 also has tenants

• namespace would be something like “cmpny”

• tenant empty in thing1 code but not in thing2

• environment as the region

• stage: test/uat/prod

• name: the cloud provider component … if an attribute is added then the name of the product would fall “almost last” while for us is more important that, say, the stage. Any suggestion from experience on how to solve this?

So does your company have multiple products and all those products are underneath a single brand?

How do those products relate and are they all employed within the same accounts?

There is the option to change the order using the field called label order

all that said, you can imagine that I seen it in one particular order for so long that it’s hard for me to get my head around it being any other way. If we’re talking about AWS, here is what those fields mean to us:

• namespace is the AWS organization. Keep it as short as possible, so that your resource names do not become too long and hit AWS limits.

• tenant is AWS organizational unit. For example, your products were owned and operated by entirely different divisions within an enterprise. It’s conceivable that you might have a different tenant. Don’t do that because it means you’re literally duplicating accounts and infrastructure.

• Stage is the operating stage of that tenant. Typical stages are dev, staging, production, uat, sandbox

• name is the thing provisioned. This may be could be your product. Or some resource associated with your product such as db-fancypants

• Attributes are things to help disambiguate this resource, especially in the case where you could have conflicting instances by name. You could use attributes for blue and green. You could use attributes if you have discrete instances like 1, 2, 3

yes, same company, one AWS organization and account, different products that share nothing. We should actually move to a multi-account setup, but still I asked to gather ideas. Thank you very much for the inputs @Erik Osterman (Cloud Posse)