Thanks @myjaffoo, this is cool! I do have a tiny issue with a "dry run" which I'll explain:
One of the reasons I love terraform plan is the fact that what you see is what you get. However, that plan is only guaranteed if you apply that same "plan.out". If dry run is set, a plan is shown. The next time dry run is not set, TFO will generate a new plan and apply it. And unfortunately, there could have been changes to the targets which means the plan might look different than before and it will be applied anyway.
This brings up a good conversation. The way the TFO volumeMount is set, it keeps all the plans in unique directories. For instance:
Generation 1 (ie a brand new TFO k8s-resource created) will store the plan in $HOME/generations/1/main/plan.out.
When changes are made to the TFO k8s-resource, generation 2 will store the plan in $HOME/generations/2/main/plan.out.
One could be clever store the last successful "dry run" generation in "$HOME/dryrun.index. We can make the following assumptions to make use of this file. The dryrun.index file contains a single line and keeps a single index. But then how does the user tell TFO that the next run should consume the plan from the dry-run? I haven't given much thought to this yet.
My initial thoughts before this PR was planning on using a "postPlanScript" to pause TFO. The script would accept some event (that I also haven't determined) to continue or just error out which stops the execution.
I'm going to brew on this PR for a while. If you think of a good way to use the dry-run's plan.out so a new plan isn't generated, I'd love to hear from you.
Maybe something like
...
kind: terraform
spec:
plan: "DryRun"
#plan: "UseDryRun" # looks for `dryrun.index`
#plan: "" # when not matching above, or null, defaults to generate plan and apply
Thanks @myjaffoo, this is cool! I do have a tiny issue with a "dry run" which I'll explain:
One of the reasons I love
terraform plan
is the fact that what you see is what you get. However, that plan is only guaranteed if you apply that same "plan.out". If dry run is set, a plan is shown. The next time dry run is not set, TFO will generate a new plan and apply it. And unfortunately, there could have been changes to the targets which means the plan might look different than before and it will be applied anyway.This brings up a good conversation. The way the TFO
volumeMount
is set, it keeps all the plans in unique directories. For instance:$HOME/generations/1/main/plan.out
.$HOME/generations/2/main/plan.out
.One could be clever store the last successful "dry run" generation in
"$HOME/dryrun.index
. We can make the following assumptions to make use of this file. Thedryrun.index
file contains a single line and keeps a single index. But then how does the user tell TFO that the next run should consume the plan from the dry-run? I haven't given much thought to this yet.My initial thoughts before this PR was planning on using a "postPlanScript" to pause TFO. The script would accept some event (that I also haven't determined) to continue or just error out which stops the execution.
I'm going to brew on this PR for a while. If you think of a good way to use the dry-run's plan.out so a new plan isn't generated, I'd love to hear from you.
Maybe something like
I'm not sold on my ideas for this lol