Hi All, does pulumi supports a native way to apply...
# general
a
Hi All, does pulumi supports a native way to apply some resources to a specific stack only?. Say I have 3 VM instances that I am preparing to be rolled out on staging stack only, and not yet ready to roll to prod stack, how can I enforce Pulumi to ignore these resources if someone do
pulumi up
on prod stack?
e
Not really. You can pass --targets to up to limit what things are changed but that doesn't sound like it would quite match this use case.
a
Thanks a lot for your response!. What would be the best practice to achieve something similar? do I need to change the way I structure my environments? as I understood from Pulumi's docs I should put my environments into different stacks !
e
I think the general thinking is that you'd use different git branches or workflows for something like this. Like merge changes up to a prod branch once staging is good, or have a workflow that only updates prod with the latest code once staging has been updated.
q
You can have a config entries that defines VM properties for each environment (one or more stacks per environment), and that would include the number of instances. Your code would use these config entries to determine what to do.
l
You can conditionally check the name of the stack, or use feature flags.
Creating a variable number of resources based on config is what the awsx Vpc does with subnets, and it causes awkward-looking boilerplate code later, when using those resources. From a code-tidiness point of view, I recommend against that option. Feature flags wrapping both the creation and use of these resources might work a little better.
What about putting the VMs in an ASG, and configuring the max/min size differently for different stacks? Set it to 0 for prod? (Don't know if ASGs can have max size 0... 🤔 )
e
Our stacks (dev/staging/prod) all have some differences, so I just select the stack in `main.go`:
Copy code
stack := ctx.Stack()
switch stack {
case "dev":
	return stacks.CreateDev(ctx)
case "prod":
	return stacks.CreateProd(ctx)
And they then select which of the shared resource-creation functions to call. We haven't got to a real release yet though, but I guess we'll have to go with Git tags to control gradual roll-outs of changes to each environment.