wondering if there's a good pattern for conditiona...
# general
s
wondering if there's a good pattern for conditionally ignoring updates to resources, for example, based on the presence of an archive. the concrete use case here is updating lambdas in application stack. i don't want to even bother trying to update the lambdas if the archive isn't present on the file system. currently, trying to bring the stack up just fails because it can't locate the zip file for my lambdas. i still want to be able to deploy this stack locally without having to build the lambdas every time. any suggestions?
hmmm, i just saw the --target flag, which might help but is a little annoying to specify all the other resources to update
b
pulumi works via you declaring your desired state and then pulumi provisioning to reach that desired state. So if you conditionally declare something and it isn't declared, you are just deleting that resource because it is no longer part of your desired state. I think you need to consider reasoning about this from a different direction. If your lambda is deployed under different conditions to the rest of your pulumi project, than perhaps your lambda shouldn't be part of that pulumi project?
s
i mean, breaking it out into another stack is definitely a solution just adds more noise. the issue here is that lambdas have an environmental dependency on the filesystem, so it's not purely declarative any more.
i realize it's a bit smelly but just being able to temp exclude a resource from reconciliation would be helpful
b
It is declarative still. You still want the lambdas to exist, and that is why they are in their code. What you are really asking is - "How do I
pulumi up
everything except my Lambdas?", and you may not like the answer but the simple answer is -
pulumi up
them separately
I personally wouldn't treat
--target
as a means of partially deploying a stack, but rather as a means of resolving issues with a corrupt or troubled stack. I think you'd be setting yourself up for state issues treating it as the former rather than the latter
s
not disagreeing with you, my preferred solution would be to deploy the lambdas as docker images so that it's entirely separate from pulumi, and we could just deploy the same tag if nothing has changed. so i realize that this is a limitation in our choice of deployment model, just having to proliferate yet-another-stack just for these feels bad
having some feature like https://github.com/pulumi/pulumi/issues/2209 would make me feel better about being hyper granular about all our resources
anyway, thanks for you input
b
I guess my thought is if you are doing this in your CI/CD it's just another couple calls to the CLI. Anyways, good luck with whatever you decide!
1
s
def not a problem from automation perspective, i just inherited an aws account with 0 automation so this is a bit of an x/y problem, since ideally i'd never be bringing things up outside of the pipeline at all!
💯 1