I'm a bit confused about how [organizations, ]stac...
# general
I'm a bit confused about how [organizations, ]stacks and projects are namespaced. My expectation was that stacks are namespaced by project, but in reality they appear to be global. Reading https://pulumi.io/reference/organizing-stacks-projects.html , is it best practice to name your stacks like
? I'm using the filesystem backend, it that's in any way relevant.
My confusion also comes from the fact that if I name my stack
only, in
output I can see
Copy code
Type                 Name
pulumi:pulumi:Stack  project-name-environment-name
We’ve actually gone back and forth over stack namespaces and things. So it is possible some of our documentation is out of date. Today a stack’s identity is its organization, project name, and stack name. So you can have multiple stacks with the same name, e.g.
. You can also have multiple stacks within the same project, e.g.
. As far as best practices, yes, we would encourage you to name your stacks something related to the environment. So your production stack would be named
, and so on. Before we changed the stack identity model (which was a month or so ago IIRC), that meant you needed to name things
. But now you should be able to just name your stacks
. (And it will be OK, since we use the project name as part of its identity.) /cc @bitter-oil-46081 who can cover this in better detail.
Right now due to a bug there are not namespace by project when using the filesystem backend. It is something we are going to fix.
Hm, I'm pretty sure that I couldn't create a stack with the same name as one in a different project.
What Chris said above applied when using pulumi.com to store state. For now, I would recommend that you just name them <project-name>-<stack-name> when using the filesytem backend and then you can rename them when the issue is fixed.
Right now due to a bug there are not namespace by project when using the filesystem backend.
Oh, ok, that was my best guess, too.
Would that only rename the stacks and leave all other resources untouched?
That's not really a big deal, only that I need additional logic to extract the actual environment name out of the stack name.
out of
Last question, does
expect only that
name? Or should it be
I guess I'll figure it out for myself, but was just curious, and not at my working machine ATM.
, both would probably work. If I recall correctly, the API was written in such a way that we would automatically support newer and older stack identities seamlessly. But we will report an error if it is ambiguous. (e.g. if two stacks have the same name, and only differ via project name.) But when using the local backend, I cannot say for sure.
Thanks all, I'll get back to you if I have further issues!
Right now due to a bug there are not namespace by project when using the filesystem backend.
@bitter-oil-46081 Do you know if there's an issue I can follow?