Is there any way to get the config from a different stack within the same project? Running against stack_a i want to get a value from the config of stack_b… ?

You can expose the config property as an output and use a stack reference to achieve this: https://www.pulumi.com/learn/building-with-pulumi/stack-references/

yes i know that. Unfortunately this pattern requires stack_a to run before stack_b can reference something. I was hoping to avoid this.

Alright mate

Cheers m8. I’m gonna use a 3rd party yaml parser to read the other configs for now.

If it's config for stack_a, then shouldn't it be in Pulumi.stack_a.yaml? It could be in both, but it has to be in stack_a...

Yea ideally, I agree. What if stacks are separated by vpcs and connected by a tgw… and one side of the routing relationship needs to know about a CIDR defined in the other. Any ideas on how to best architect this kind of a scenario?

I've done this (well, VPC peering, same-same but different), and I went with two projects, one of which has to be `up`ped twice. I don't like this solution; if I were re-doing that code now, I'd go with three projects.

We export the public/private subnets from our base infra stack which does all the networking etc

I’m trying to avoid needing to go back-and-forth between two (or more) projects which expose data to each other… where the only way to get to a “complete” deployment is to run A then B then A again. This is a circular dependency. I like referencing config of another stack (or project) because I can deploy A and consider it “fully” deployed. B still depends on A’s exports… but we don’t need to deploy A again for the routing to work. I think that a third “config” project/stack is a good pattern, as @little-cartoon-10569 mentioned… but it adds more complexity and layers and still requires 3x “up” cycles. Also the data i need is config based… not stack-generated… so having a project that reads it and then exports it seems like unnecessary extra steps… however this might be the canonical Pulumi way…

I don't think that's canonical. That's (imo) a preference thing. Personally, I think that config that's required by more than one project usually shouldn't be retrieved from one of those two projects: it should be retrieved by both projects from a central config location. This decouples the change, and allows you to deploy in either order. If one project gets the config from the other project, then it cannot get new config values until after the other project has been upped. And I don't think I'd always want to be forced to up project A just to up project B.. what if I want to test wrong values?

Config and outputs are different. Config is already written and can be referenced at any time. Outputs / exports require a stack to be run first.

Yes, and the current / last question as I understand it is: is making config from one project available to another project via outputs / stack references canonical in Pulumi? I think it's not canonical. But it is feasible. I've just remembered that there is a popular technique of having a config-to-output project, with no other resources. Even though this does require the extra

up

to publish configs as stack references, the friction is a lot lower than `up`ping a project with real cloud resources. This approach might be considered canonical, at least right now. Personally, I prefer not using Pulumi like this, since it's not a configuration tool. But this approach works and is popular.

That’s very interesting @little-cartoon-10569! So basically using a dedicated project to only store data in the config file, then transporting that data into stack outputs to make them available as a kind of central config store for other projects… ? If i understand correctly? That would add another project, and another “up” dependency… but keep things neat and using a “supported” way of retrieving the data…

Yes. And because the up in that project is both very fast, and has no risk of changing in-cloud resources, it's not a big thing to put

pulumi up

into every yarn/npm script that needs it. It's low friction.