KEP96 - Rename Tasks and Evaluations to Hooks #105
Conversation
|
|
||
| - Pre-deployment at a workload level | ||
| - Pre-deployment at an application level | ||
| - Pre-deployment at a workload level |
There was a problem hiding this comment.
Do you mean "Post-deployment at a workload level" here?
| - Pre-deployment at a workload level | ||
| - Pre-deployment at an application level | ||
| - Pre-deployment at a workload level | ||
| - Post-deployment at a workload level |
There was a problem hiding this comment.
I may be missing something but it seems like this requires changing the names of the annotations and sort of blurring the distinction between evaluations and tasks, at least at the configuration level. Do we have evaluations and tasks that are executed only at the KeptnApp level? I thought all the evaluations and tasks defined for the individual workloads were executed for any KeptnApp that includes those workloads.
I'm looking forward from comments from people with more knowledge!
|
|
||
| ## Explanation | ||
|
|
||
| Hooks are a fairly standard and well understood software mechanism. So rather than referring to tasks and evaluations - then attempting to explain the difference. |
There was a problem hiding this comment.
To me, the distinction between an evaluation and a task is fairly obvious. What I think is confusing is the apparent inability to do an evaluation then trigger a particular task as a result of the evaluation, although this is a deliberate design decision. To clarify this, we need a good, complex example of a KeptnApp that includes multiple workloads and uses ArgoCD to implement the "if-this-evaluation-result-then-do-this-logic" -- and I'm not sure whether either the KeptnEvaluation or KeptnTask will be part of that logic.
There was a problem hiding this comment.
"To me, the distinction between an evaluation and a task is fairly obvious".
In a way, that's exactly my point in this PR. We (as those who know about Keptn) know about these terms. But if you are new to Keptn (and probably new or new-ish) to DORA / SRE / SLIs / SLOs etc. then a Keptn Task and a Keptn Evaluation will mean very little to you.
The term "hooks" is more generic, more widely used and thus more approachable. We don't remove the Keptn Task and Keptn Evaluation nomenclature - we just explain that both "Keptn tasks and Keptn evaluations" are types of hooks.
KEP96
Proposes we (as a project) change the way we talk about KeptnTasks and KeptnEvaluations.
Rather than confusing users, this KEP proposes we discuss both as "hooks". There are thus two types of hook a task and an evaluation.
Note: This doesn't change the underlying implementation of CRDs. It's (probably) purely a documentation / messaging thing.