https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
q
Projects seem to be a way of grouping stacks, which is fine
However, as stack names need to be unique, you end up being rather verbose
Example: Project: 
rawkodes-modern-life
Stack can't be 
production
, due to the unique constraints, so it ends up 
rawkodes-modern-life-production
It just feels really clunky
And the required 
Pulumi.stsckname.yaml
is annoying too
Copy code
Type                                 Name                                                  Status      Info
 -   pulumi:pulumi:Stack                  rawkodes-modern-life-rawkodes-modern-life-production  deleted
My OCD isn't coping 😂
The more I'm playing with this, it seems to be a wrapper around Terraform's workspaces?
Ah, now I see the GCP definitions are generated from Terraform's provider. Is this how most of Pulumi works?
w
The project/stack structure is unrelated to Terraform Workspaces (though I suppose most solutions to providing separate environments and deployments of a single project have some fundamental similarities :-)). You are right that because the identity of a stack is 
<user/org>/<stackname>
, the stack name generally has to be a little more verbose to remain unique within an organization. We used to have identity tracked as 
<user/org>/<project>/<stackname>
, which allowed the stack name to be something more like 
production
, as it was scoped to a project. It sounds like this would align closer with how you wanted to think about things. We're continuing to look at refactoring things in this direction again - but for now you can generally map into this mental model just be making all stacknames look like 
<project>-<stack>
(which appears to be what you are doing). The fact that that 
pulumi:pulumi:Stack
row duplicates this information is just a bug - see https://github.com/pulumi/pulumi/issues/1417.
I see the GCP definitions are generated from Terraform's provider. Is this how most of Pulumi works?
The AWS, Azure and GCP resource providers build on top of the 
terraform-resources-providers
for these platforms, but use the 
pulumi
CLI and engine for driving deployments.
q
Thanks for the info
<user/org>/<project>/<stackname>
makes a lot more sense to me 🙂
t
I also had similar concerns, trying to grasp how stacks should be used and how to give them shorter names. Stack local to project would make sense to me. I don't have large infra though, so my only use case for multiple stacks were deployments on different cloud accounts.
c
I also expected 
<user/org>/<project>/<stackname>
, and and spent 10 mins creating and destroying stacks until I stopped being confused.
g
@quiet-wolf-18467 @tall-librarian-49374 @cool-helicopter-70130 I had the exact same observation about stack / project names a couple of days ago (https://pulumi-community.slack.com/archives/C84L4E3N1/p1537128934000100). Now just just created a github issue out of it. Please add your vote to the gh issue 🙂 https://github.com/pulumi/pulumi/issues/2039
👍 2
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by