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?
03/17/2021, 6:34 PM
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?
03/18/2021, 7:32 AM
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?
03/18/2021, 2:26 PM
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.
So the child stacks get stack outputs, the .get() the resources they need, create their additional resources and attach them.