Revert "Handle Jobs with ttl_seconds_after_finished = 0 correctly"

[justinmchase]

Reverts #2596

Per issue #2649, please revert this breaking change which regresses a critical feature.

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[arybolovlev]

Hi @justinmchase,

Thank you for reverting this change and properly reporting the related issue. Indeed, it looks like a breaking change and we need to find a better way to cover both scenarios without introducing a breaking change in the minor release.

I have left a small comment. Once it is addressed we can merge this change and cut a patch release.

[justinmchase]

I updated the release notes files as requested and merged upstream main.

[arybolovlev]

Thanks, @justinmchase!

[dmpakhar]

This change broke functionality, when job should be created once and then deleted.
In my scenario k8s job should be launched only once. Now this job recreates every apply and there are no ability not to skip creation of this job in the second run or small changes that would not require execution of the job.

[justinmchase]

@dmpakhar Is it possible to add a separate field to get the behavior you want without regressing the behavior that is currently expected when ttl seconds after finish is 0?

If it helps, I will tell you that our Job is running a migration pod, the migration pod does run on every deployment but internally it is keeping track of the state of migration steps and applying them only once. This is a pretty standard way of handling run-once behavior rather than trying to manage it with terraform and kubernetes.

[dmpakhar]

@justinmchase
Hi,
I think this can be managed as an extra flag. From my perspective this behaviour should be defined via extra var. this will make logic clear for everyone.

Now we went in same issue, when same parameter changes behaviour.

I think execute_once/recreate_after_finished = true/false variable may be a good idea