https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
b
Do you set up the directories yourself? With azure blob container - it just throws everything into root like normal .pulumi folder..
b
in blob storage directories aren't really "directories" right? They're just simulated that way for the UI - it's really just pathing. So when I give my project a state backend url this is the path that I use: 
s3://{bucketName}/{projectName}/
And that effectively gives it its own directory.
b
exactly what I was wondering about - thanks 🙂
w
however, that breaks stack references.
b
true. I don't use them
it's worth mentioning also that filestate backends do not support locking on stack updates by default. Meaning you'll get all kinds of weird issues if concurrent updates on the same stack go out. this PR was recently approved gating the locking mechanism behind an ENV var: https://github.com/pulumi/pulumi/pull/2697 and this issue is open to make it the default: https://github.com/pulumi/pulumi/issues/6536 It's fairly new parameter so not really documented yet.
b
mm. i do like stack references though.
oh wow - was wondering if lockfile was being worked on, thats excellent
p
With stack references and filestate backend the only alternative (afaik) is to utilize the naming scheme where you have for example the project name in the stack name. It's a bit clunky but it does work
w
yup, that's what I've detailed in that post.
I thought Azure Blob used the Lease for locking though
b
I wonder.. in a stack reference with azblob backend, would stack B lock the stack A state if it referenced it?
or even with the new locking system. technically a state reference just reads the output as a one-off right?
b
a stack reference is just going to be deserializing the state file, it shouldn't be locking anything
4 Views
Open in Slack
PreviousNext
Powered by