https://pulumi.com logo
Join Slack
Powered by
Hi, I found that I can't create stack with same n...
# general
b
Hi, I found that I can't create stack with same name under different projects Details is illustrated in https://github.com/pulumi/pulumi/issues/7728 I assume we should be able to create stack with same name in different projects right? Like to create 
dev
in both project A and B
p
You should. Actually, I’ve got 2 projects with linked stack names.
The only diff I was able to spot right now (without further analysis) is that you’re using GCS as state storage instead of Pulumi Service.
b
that's what I thought but when I try to do so, I always get 
stack dev already exists
oh? I have tried both 
local
and 
gcs
, none of them supports that feature. With that said, seems like only pulumi service supports this feature then?
p
I’m not suggesting that it’s not possible while using GCS - I haven’t checked that.
I’ll try to take a look at that but I don’t have much free time right now. Could you double check if that case is reproducible for you while using Pulumi Service? You should be able to test that using free individual account.
b
will try that for sure
p
Ok, I’ve tried to repro this (using Pulumi Service) and everything works just fine.
I was able to create two projects using:
Copy code
pulumi new google-native-typescript --dir <DIR_NAME>
with the same stack.
b
I just tested with pulumi service as well it works!!!
I think the official doc should make this point clear that only pulumi service support that feature
thanks for pointing this out, I thought I made some weird mistake myself, now it's clear
p
Ok, I think I have the anwser for you
I don’t have time to play with the GCS backend but I’ve looked into the local backend
b
ya found that in 
local
, all stack files are placed in same folder
p
When you configure local backend e.g. with:
Copy code
export PULUMI_BACKEND_URL=file:///tmp/tests/state
Stacks are stored directly under that directory and they do not include project name.
b
with only stack name as file name, for instance 
dev.json
etc.,
p
exactly
so if you want to use something other than Pulumi Service, you’re responsible for configuring the state backend properly
e.g. by providing different directories for each project in case of local backend
and I guess by providing different buckets (or path prefix) in case of GCS/S3
b
I see! that's a brilliant catch thanks
🙌
p
I cannot advice you more as I have no experience with using pulumi with other state backends but I think you’ll manage to move further with this now 🙂. If I were you, I’d confirm that the case with GCS is similar to the local backend and if that’s so, check whether you can add a prefix to bucket URL (e.g. 
<gs://my-bucket-name/my-proj>
instead of simple 
<gs://my-bucket-name>
). You can dynamically change state backend via env variable: 
PULUMI_BACKEND_URL
. Not sure if you can store it in pulumi yaml file.
b
ya that's what I am planning to test now, hopefully by doing so I can mimic what pulumi service's behavior
thank you so much sir!
p
EDIT: you should be able to configure backend using YAML file, see https://www.pulumi.com/docs/reference/pulumi-yaml/. There’s an optional 
backend
field.
b
nice, this can be much easier and switching env var back and forth
p
exactly
b
🎉
let me test it out
p
There’s just one thing that’s missing when you decide to use other state backend (other than the lack of UI) - there’s no locking mechanism that could prevent simultaneous runs of 
pulumi up
.
Although I’m not 100% sure I’m right in that matter.
b
ya, looks like pulumi service cover all those cases, whereas the others we have to do these all by ourselves
p
Ensuring that you have different paths for different projects shouldn’t be a problem.
b
definitely!
p
Ensuring you won’t have two simultaneous updates running on the same stack might be trickier.
If you have one devops guy -> no issues. If you use ONLY CI/CD and you can put restrictions on number of parallel runs -> cool. If you want to make it bulletproof, you need to wrap 
pulumi up
with some additional logic and implement simple locking mechanism (e.g. similar to what TF done in case of S3+DynamoDB).
b
With self-storage stack names are globally unique instead of project unique. The solution is to either namespace your stacks with the project name or to specify separate backends. Note that if you use separate backends than you won’t be able to make StackRecerences to different backends
There was a recent merge into Pulumi that added update concurrency locking on the file state backends
p
Arr, thanks @bored-oyster-3147 for pointing that out. Not being able to use stack references might be a real issue. @brash-quill-35776 make sure you won’t need that (I’m afraid you’ll need it sooner or later though)
b
@bored-oyster-3147 ya I was planning to prefix the stack name with project, which is not nice looking but not too bad anyway
p
that actually seems like the easiest solution without any downsides except “not so pretty stack names”
b
ahhh 
StackReference
is a requirement for my project. then in this case, I have to prefix then
ya, agree
p
There was a recent merge into Pulumi that added update concurrency locking on the file state backends
I didn’t know that. Are there any docs created describing that?
b
I believe this is what I was thinking of. So it was implemented previously and can currently be enabled via an environment variable and they haven’t yet made it default
🙌 2
Open in Slack
PreviousNext
Powered by