Hello Pulumi community! I'm heading up a team that's decided to give Pulumi a try for a rather substantial CI/CD architecture - more on that to come, I'm sure. For now we're just taking Pulumi for a spin and testing some of our ideas out, and we're noticing something peculiar that we haven't come across in any of the docs. When I create a resource such as this:

const resourceGroup =
    new azure.core.ResourceGroup(
        `retrospect-${envName}-infra`,
        {
            location: "westeurope"
        }
    );

Pulumi adds an auto-generated suffix to the name, like so:

retrospect-dev-infra5bf12d3a

Firstly, why is it doing this, and secondly, how can we override this behavior? We'd like to avoid that because we'll be encoding project and stack names into our resource names where necessary, so the random suffix just makes things more cluttered..

Pulumi auto-generates the suffix to reduce, eliminate, name collisions. For example, you may want to deploy your app multiple times. Here is how you can override it:

const resourceGroup =
    new azure.core.ResourceGroup(
        `retrospect-${envName}-infra`,
        {
            name: `retrospect-${envName}-infra`,
            location: "westeurope"
        }
    );

Ah! 💡Thanks!

Note that while you can override it, it's probably not an awesome idea to in most cases.

@boundless-monkey-50243 I understand this concern, and it's a reasonable default behavior for that reason. And I agree 100% on using exported IDs downstream, we fully intend to do this, and never rely on "shared knowledge" of resource names between programs. But, since we intend to always include the stack name in all resource names, I think it may be a better choice for us to override the suffixing, and instead get cleaner resource names.

I understand what you're trying to do. What I'm trying to say is that it causes nontrivial failure cases that you otherwise never have to think about. (I've attempted to do exactly what you're doing and stopped for the reason I describe.)

@boundless-monkey-50243 OK perhaps I'm not fully understanding the issue you are pointing out then.

Yes. What I'm saying is if two people try to use

foo

, it'll collide, and you're offloading the fixing of that problem onto your code rather than the stuff built for it

OK, I see what you're saying. You mean if your team is distributed enough that one member might try to create a resource by some name X, and another member tries to create an unrelated resource by the same name X, in a whole other component in another package, potentially in another repo, both unaware of the other, even though both are doing the right thing and embedding the stack name in their resource name, it would still collide.

Not just an unrelated resource, but an instance of the same stack without the same state store.

Same stack without the same state store? How does that happen?