KEP 93: Lifecycle Toolkit - on-success and on-error-tasks

[thschue]

No description provided.

[grabnerandi]

Why would you define the on-success and on-failure on the task or evaluation? Why not add them as a separate option on the workload or the KeptnApp? The use case for me would be to react to on-success or on-failure in case any task or any evaluation fails as part of a pre- or post deployment check, e.g: Notify users about a failed post-deployment validation. For me it would make more sense to therefore provide this on the workload and App level instead of the individual task

[thschue]

Why would you define the on-success and on-failure on the task or evaluation? Why not add them as a separate option on the workload or the KeptnApp? The use case for me would be to react to on-success or on-failure in case any task or any evaluation fails as part of a pre- or post deployment check, e.g: Notify users about a failed post-deployment validation. For me it would make more sense to therefore provide this on the workload and App level instead of the individual task

Thank you @grabnerandi for this feedback!

This might also be an option. We could enhance the KeptnApp with EvaluationFail/Success and TaskFail/Success tasks. For workloads, we could add corresponding annotations. What do you think about this?

[agardnerIT]

I like this idea but it brings to mind something else: retryLimit: 3. Whereby a failed task would be retried 3 times.

What would that behaviour look like? Would my on-error fire 3 times or just once (so long as the final retry failed). As a human using KLT, I'd probably want to know that my tasks are failing - even if, as they say, third time is the charm - and the task eventually succeeded - I'd want to dig into why the first 2 failed. That said, I wouldn't want alert spam (assuming my on-error task notified me on Slack or something.

[AnaMMedina21]

I like what @grabnerandi mentioned of defining them at KeptnApp level, and see what @agardnerIT, is there any way that the tasks can be executed and then those results aggregated and then sent in one response back to KeptnApp?

[thisthat]

in a TC discussion, we identified the following:

• allowing on-success/failure task execution could lead to cycles.
• we could have a new (pre/post) phase that has the information if the previous task/eval succeeded/failed. This brings extra complexity for implementing a reconciliation loop at KeptnApp and KeptnWorkload and their instance versions.
• limit to a single new Task and forbid following on-success/failure hooks.