https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
m
We generally follow the stack pattern of: 
stackName.environment.region
e.g. 
cool-service.prod.us-west-1
If there are any required services in a specific region, the project explicitly declares a secondary explicit aws provider
g
wait.. stack names can contain dots? ..
😂
Yeah so I was thinking some of those edge cases might be when you are say, creating a VPC in one region, and then in another region, and want to manage say peering connections between both of them in the same pulumi run… but it might still be better to separate that. I dunno.
m
We have a "primary region" and a concept of "base infrastructure". The base infrastructure has outputs that the "child" stacks use via StackReference. In the case where we need global infrastructure resources we do 1 of two things: 1. Treated as a manual one-off edge case and documented 2. Deployed with our "primary region" Some stacks only exist in one region, the primary region isn't always included for those projects.
l
All my use cases to date have called for separate region-based providers within a stack. If the prod stack has resources in two regions, then that's managed in one stack.
The only time this has bitten us is with VPC peering. Where we need to update a resource (in VPC 1) based on another resource (in VPC 2) that can't be created until after the first resource is created.
Solved using conditionals. Takes 2 ups to deploy from clean, but it's all good from then on.
g
Nice. Thanks for the input on this
a
I missed this thread but we're following the 2nd pattern you describe above, where when one stack contains resources for multiple regions, all resources use an explicit provider
I felt that it looked better in 
pulumi plan
to have everything nested under an explicit provider than to have default provider + child resources for some resources and then a provider hierarchy for other resources
g
@alert-glass-49407 I agree — I prefer being explicit in these situations. It avoids surprises or confusion.
a
I had a mild panic attack when I realized that our SSO was misbehaving (not pulumi's or AWS' fault, to be clear 🙂) and I realized that the default provider for a complex multi-account-multi-region pulumi program might have deployed a ton of resources in a disjointed manner
Fortunately that was not the case, we were fine, but I am definitely in favor of being explicit now
Open in Slack
PreviousNext
Powered by