Hi again! I have some more questions as I have dif...
# general
g
Hi again! I have some more questions as I have difficulties to grasp the concepts and how pulumi is designed. I had some comments earlier that it should be easier to work in scenarios where we have just one stack per pulumi program (e.g. by introducing an implicit stacks with an option to add more stacks if needed). After thinking about it more I came up with the questions below: 1. What’s the difference between pulumi program and pulumi project? Are they the same thing? Is it possible to have more than one pulumi program in one pulumi project? If yes, when is it useful? 2. It seems that stacks are the most important entities in pulumi - they keep state of resources from a specific pulumi program. But they are “owned” by a pulumi project, at least this is how they are shown in app.pulumi.com - and still their names have to be unique in my whole account/organization. That is really misleading for me. If they are part/owned by a pulumi project, shouldn’t their names be scoped to pulumi project instead? 3. If stacks are the most important entities in pulumi (they are in my opinion), shouldn’t they be the top level resource in an account organization and their pulumi program/project be just a metadata by which we could be able to group them if we need to instead? 4. Maybe pulumi projects should be just the pulumi program concept (local to the runtime environment where they are executed) and should not be the top level entities in app.pulumi.com? Maybe we should have just stacks that are results of running a pulumi program and the main link between a pulumi program and a stack should be local to the program (with just a metadata information like a label or a tag in app.pulumi.com like the idea in question 3)?
w
You may want to take a look at https://github.com/pulumi/pulumi/issues/2039. We actually plan on moving to a more explicit hierarchy of <org>/<project>/<stack> to make this more clear/explicit.
c
Hmm, so I don’t know that I fully understand the questions, but I find it helpful to think of the TS/JS/Python code of a Pulumi application to be a description of desired cloud resources — this, in turn, is driven by the
pulumi
CLI, which can re-use those resource descriptions in multiple stacks. So hopefully that’s a helpful start.
g
Thank you @white-balloon-205, so it seems stack names will be scoped to pulumi projects. Then I guess I could have a convention that in projects with a single stack I could name it
default
(or similarly).
c
So resources are managed Pulumi, in the context of these stacks. As luke says, these two have a hierarchy that is relevant to the organization that uses those resources. org, project, stack, etc.,
g
@creamy-potato-29402 one of the issues I have is the usage of pulumi program in one places of the docs and pulumi project in others. I am lost if they describe the same thing 🙂
Is it possible to have one pulumi project that contains more than one pulumi program?
c
see luke’s response, he pretty much covers it.
w
Is it possible to have one pulumi project that contains more than one pulumi program?
No. A project is a Pulumi.yaml file, and that file specified the
runtime
and
main
entrypoint of the program to execute for the deployment of the project.
one of the issues I have is the usage of pulumi program in one places of the docs and pulumi project in others. I am lost if they describe the same thing :
Yes - it does look like we are a little loose in using the word "program" in some places we should use "project". Technically, these are 1:1, so it doesn't really matter - and in many cases the prose really is referring to the program that a project will run, vs. the project itself. But I do see a few cases where we should be crisper here.
👍 1
g
I’m still learning Pulumi so I might misunderstand some of the concepts and how they are related with each other - all these answers make it very clear now.