Hi I found that I can t create stack with same name under di

Question

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

prehistoric-activity-61023 · Answer

You should Actually I ve got 2 projects with linked stack names

prehistoric-activity-61023 · Answer

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

brash-quill-35776 · Answer

that s what I thought but when I try to do so I always get `stack dev already exists`

brash-quill-35776 · Answer

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

prehistoric-activity-61023 · Answer

I m not suggesting that it s not possible while using GCS I haven t checked that

prehistoric-activity-61023 · Answer

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

brash-quill-35776 · Answer

will try that for sure

prehistoric-activity-61023 · Answer

Ok I ve tried to repro this using Pulumi Service and everything works just fine

prehistoric-activity-61023 · Answer

I was able to create two projects using ```pulumi new google native typescript dir lt DIR NAME gt ``` with the same stack

brash-quill-35776 · Answer

I just tested with pulumi service as well it works

brash-quill-35776 · Answer

I think the official doc should make this point clear that only pulumi service support that feature

brash-quill-35776 · Answer

thanks for pointing this out I thought I made some weird mistake myself now it s clear

prehistoric-activity-61023 · Answer

Ok I think I have the anwser for you

prehistoric-activity-61023 · Answer

I don t have time to play with the GCS backend but I ve looked into the local backend

brash-quill-35776 · Answer

ya found that in `local` all stack files are placed in same folder

prehistoric-activity-61023 · Answer

When you configure local backend e g with ```export PULUMI BACKEND URL=file tmp tests state``` Stacks are stored directly under that directory and they do not include project name

brash-quill-35776 · Answer

with only stack name as file name for instance `dev json` etc

prehistoric-activity-61023 · Answer

exactly

prehistoric-activity-61023 · Answer

so if you want to use something other than Pulumi Service you re responsible for configuring the state backend properly

prehistoric-activity-61023 · Answer

e g by providing different directories for each project in case of local backend

prehistoric-activity-61023 · Answer

and I guess by providing different buckets or path prefix in case of GCS S3

brash-quill-35776 · Answer

I see that s a brilliant catch thanks

brash-quill-35776 · Answer

raised hands

prehistoric-activity-61023 · Answer

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 slightly smiling face 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 `` instead of simple `` You can dynamically change state backend via env variable `PULUMI BACKEND URL` Not sure if you can store it in pulumi yaml file

brash-quill-35776 · Answer

ya that s what I am planning to test now hopefully by doing so I can mimic what pulumi service s behavior

brash-quill-35776 · Answer

thank you so much sir

prehistoric-activity-61023 · Answer

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

brash-quill-35776 · Answer

nice this can be much easier and switching env var back and forth

prehistoric-activity-61023 · Answer

exactly

brash-quill-35776 · Answer

tada

brash-quill-35776 · Answer

let me test it out

prehistoric-activity-61023 · Answer

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`

prehistoric-activity-61023 · Answer

Although I m not 100 sure I m right in that matter

brash-quill-35776 · Answer

ya looks like pulumi service cover all those cases whereas the others we have to do these all by ourselves

prehistoric-activity-61023 · Answer

Ensuring that you have different paths for different projects shouldn t be a problem

brash-quill-35776 · Answer

definitely

prehistoric-activity-61023 · Answer

Ensuring you won t have two simultaneous updates running on the same stack might be trickier

prehistoric-activity-61023 · Answer

If you have one devops guy gt no issues If you use ONLY CI CD and you can put restrictions on number of parallel runs gt 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

bored-oyster-3147 · Answer

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

bored-oyster-3147 · Answer

There was a recent merge into Pulumi that added update concurrency locking on the file state backends

prehistoric-activity-61023 · Answer

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

brash-quill-35776 · Answer

< bored oyster 3147> ya I was planning to prefix the stack name with project which is not nice looking but not too bad anyway

prehistoric-activity-61023 · Answer

that actually seems like the easiest solution without any downsides except not so pretty stack names

brash-quill-35776 · Answer

ahhh `StackReference` is a requirement for my project then in this case I have to prefix then

brash-quill-35776 · Answer

ya agree

prehistoric-activity-61023 · Answer

gt 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

bored-oyster-3147 · Answer

I believe <https github com pulumi pulumi issues 6536|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