https://pulumi.com logo
#general
Title
# general
p

powerful-football-81694

01/01/2019, 1:40 PM
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:
Copy code
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..
b

billowy-television-23506

01/01/2019, 2:46 PM
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

powerful-football-81694

01/01/2019, 4:41 PM
Ah! 💡Thanks!
b

boundless-monkey-50243

01/01/2019, 6:33 PM
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

powerful-football-81694

01/01/2019, 7:02 PM
@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

boundless-monkey-50243

01/01/2019, 8:52 PM
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

powerful-football-81694

01/01/2019, 9:51 PM
@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

boundless-monkey-50243

01/01/2019, 9:52 PM
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

powerful-football-81694

01/01/2019, 9:55 PM
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

boundless-monkey-50243

01/01/2019, 9:55 PM
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

powerful-football-81694

01/01/2019, 9:57 PM
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.