This message was deleted.
# general
s
This message was deleted.
l
Use a different Pulumi name for each resource. Let Pulumi continue with its suffixes, they solve a lot more problems than they create. If the specific problem is with resources in different stacks having the same name, I see two options: 1. Less good: use a different provider / region / account for each stack to avoid clashes at the cloud end. 2. Better: use the stack name or equivalent per-stack discriminator in the Pulumi name, to avoid clashes at the state end.
g
Maybe I'm not wording my problem well enough or I'm missing something. The Pulumi stack names for each feature would be different. With own storage backend, let's assume stack names 'feature-a-dev', 'feature-b-dev', 'feature-c-dev'. Feature A will provision a storage account with a URL that looks like 'feature-a-devxyzabc.blob.storage.net' or such. If feature B and C aren't provisioned as part of the same infra stack, how will they get the updated storage URL for the new deployed feature A?
p
I intend to, in situations like that, have the CICD deploy B and C right after A is deployed, so the name can be exported from stack A into B and C, of course this doesn't work in all situations, i.e. where you really want to have both the resources A-1 and A-2 so there's no downtime in the transition from B-1 to B-2. In situations like that I'm currently either explicitly naming the objects so they don't change, or putting A B and C all into the same stack. (I say intend as I'm building this at the moment and currently manually deploy all the downstream stacks when I change something upstream)
👍 1
l
If they're in different Pulumi backends (you're storing state in different S3 buckets or similar), then Pulumi won't solve this problem for you. If you store all the stacks in the same backend, then you use stack references to get values from other stacks.
👍 1
If project scheduling is critical, you should look into automation-api. It is very useful for managing dependencies between projects by wrapping them in coordinating code.
👍 1
g
Yeah stack references is possible, but it means updating all the dependencies and encounter possible downtime after feature A has been deployed and before all dependent features' settings have been updated with the new stack references.
I think on that basis, I'll go for explicitly naming the resources. Thanks for the feedback chaps.