would that be better served updating the source st...
# automation-api
b
would that be better served updating the source stack, or would it be better to create a dependent stack that references the resources of the first?
m
I’m not sure I fully understand, can you elaborate? Do you have some shared/base infrastructure with a centralized role, then instances of another stack that you want to modify a centralized role to add new policies?
b
Sorry about the delayed response - got pulled away by kids, and then timezone lag crept up on me 😉 So let's say I have the following configuration: • Project: BaseInfra ◦ Stack: environment1 ◦ Stack: environment2 Now - the environmentX stacks in BaseInfra are only there to create and manage the top-level resources as it stands today - basically everything from kubernetes clusters and pools (but not contents), networking, storage, security, etc. What I'm planning on adding is a capability to dynamically assign permissions to users for certain resources - le't say kubernetes role access + whitelisting of the users ip in the kubernetes network config. Given that i'm using automation (and I want this kind of thing to be timeboxed) I'll be using a separate database to store that desired state rather than pulumi stack config yaml (like I have with the environmentX stuff). Would it be better to try to merge the database config with the current stack config - or would it be better to set up environmentXaccess stacks that inherit from environmentX but are otherwise independent?
m
I would say the latter. A an example, we have a project where base infrastructure sets up a shared ALB for gameservers, then the gameserver stacks attach their own listeners to that ALB.
❤️ 1
So the child stacks get stack outputs, the .get() the resources they need, create their additional resources and attach them.