https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
b
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:
Copy code
const resourceGroup =
    new azure.core.ResourceGroup(
        `retrospect-${envName}-infra`,
        {
            name: `retrospect-${envName}-infra`,
            location: "westeurope"
        }
    );
p
Ah! 💡Thanks!
b
Note that while you can override it, it's probably not an awesome idea to in most cases.
I would strongly recommend instead exporting your resource IDs out of your stack and using that exported ID downstream.
(People can more easily do the Wrong Thing if two Pulumi users try to use the same resource names in two unrelated stacks.)
p
@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.
b
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.)
The intersection of 
pulumi refresh
and mutable commands with more than one runner (even more than one unintentional runner) can be easily avoided by just staying on the rails.
p
@boundless-monkey-50243 OK perhaps I'm not fully understanding the issue you are pointing out then.
You said:
if two Pulumi users try to use the same resource names in two unrelated stacks
b
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
And that happens more than you would think in a CI environment unless you designed it from the jump to not do that.
Been there, got the scars. 😉
(i.e., now you need two instances of 
ENG-101
for some reason)\
But there are also weird edge cases if, for example, an 
ENG-101
stack already exists and another one doesn't but ill-considered code attempts to create one, then destroy it on failure
They're manageable...but you start treating stuff as pets rather than cattle when you jump through a bunch of hoops just to have friendlier names. In the cloud, all your names are secretly random numbers anyway, etc.
p
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.
b
Not just an unrelated resource, but an instance of the same stack without the same state store.
(again, it's something you can design around...but doing so also makes some suggestions as to mindset that you may not want to inculcate into your people)
p
Same stack without the same state store? How does that happen?
Anyway, I take your point. It's food for thought, and I appreciate the insight. In our case, I think our team composition and project structure is such that this will never be an issue.
Open in Slack
PreviousNext
Powered by