https://pulumi.com logo
#general
Title
# general
s

strong-helmet-83704

09/14/2022, 5:02 AM
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… ?
v

victorious-church-57397

09/14/2022, 6:29 AM
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/
s

strong-helmet-83704

09/14/2022, 6:30 AM
yes i know that. Unfortunately this pattern requires stack_a to run before stack_b can reference something. I was hoping to avoid this.
v

victorious-church-57397

09/14/2022, 6:38 AM
Alright mate
s

strong-helmet-83704

09/14/2022, 6:40 AM
Cheers m8. I’m gonna use a 3rd party yaml parser to read the other configs for now.
l

little-cartoon-10569

09/14/2022, 7:21 AM
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...
s

strong-helmet-83704

09/14/2022, 8:20 PM
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?
l

little-cartoon-10569

09/14/2022, 9:06 PM
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.
A sequenced set of Pulumi projects: network-a project, network-b project (which includes initiating the peering connection), and the peering project (which does almost nothing, just accepts the peering using references from the other two projects, and adds some routing).
v

victorious-church-57397

09/14/2022, 9:54 PM
We export the public/private subnets from our base infra stack which does all the networking etc
Makes it super easy to consume from the rest of our infra
s

strong-helmet-83704

09/15/2022, 12:11 AM
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…
l

little-cartoon-10569

09/15/2022, 6:13 AM
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?
👍 1
s

strong-helmet-83704

09/15/2022, 6:39 AM
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.
l

little-cartoon-10569

09/15/2022, 8:09 PM
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.
👍 1
👀 1
s

strong-helmet-83704

09/15/2022, 10:05 PM
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…
l

little-cartoon-10569

09/15/2022, 10:16 PM
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.
6 Views