I’ve noticed that if I do a `pulumi up` and get a ...
# getting-started
s
I’ve noticed that if I do a
pulumi up
and get a summary of proposed changes, then modify the code prior to
approving
the changes, the modified changes get put in place instead of the previously proposed changes. Is this expected/normal in the Pulumi world? It is different than what I am accustom to coming from Terraform. Is there a way to preserve the behavior like Terraform, where a specific plan output can be what is approved/applied?
b
Hi Jeremy. No, this isn't currently possible - pulumi operates in a different way to terraform. We have this issue open for it: https://github.com/pulumi/pulumi/issues/2318 but it's a significant investment
happy to go into more detail about why this is different if needed, but the short answer is unfortunately "no"
s
Is the difference/challenge covered here? I’m struggling with how to use Pulumi in an environment where specific infra changes need to be understood/approved prior to apply.
b
yeah, that basically covers it in a nutshell. Our model works on the idea that outputs are resolved like futures, so if you put a resource creation inside that future, it won't be consistent. you may have seen situations where terraform will expect you to do multiple
applys
- we don't have that issue, however it does mean your use case isn't currently supported
s
Thanks. Maybe, because I can’t imagine life without that feature, I’m missing how companies get comfortable with pulumi baked into CD automation on larger scale. Will have to dig more… Also, great talk last Friday at KCDC, thanks for that.
b
i'd love to get an idea of where the apprehension is? is it the fact you can't be descrptive in what you're doing?
s
I’m thinking of use in an environment that currently uses ‘plan’ output for change approval. I know Terraform can’t guarantee that all of the proposed changes will be made, but I’m thinking it can guarantee that no more than those changes will be made, because at that point the input is the plan, not the source repository, and not the implemented state. I’m trying to think whether a combination of test automation, clever plan/run execution timing incl hash validation, automated deployments, and maybe protected resources for the most critical components (databases/backups/state), would be sufficient to provide the same controls.