Hi, I got a specific question about how you deal with dependencies between different features that have separate CI/CD pipelines with their own infra stacks. Particularly when it comes to the auto-naming and the random suffix that gets added onto resources. Do you simply go for the option by explicitly naming, so the random suffix isn't there? Say I have a feature A that provisions a storage account. And I might have a feature B and C that need access to the storage account & URL. Each delta infra deployment of feature A changes the resource URL via the random suffix, which might be configured for feature B and C via appsettings, but is effectively out of date with every deployment of A. What's the advice here?

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.

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?

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)

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.

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.