Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

KEP96 - Rename Tasks and Evaluations to Hooks #105

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

KEP96 - Rename Tasks and Evaluations to Hooks #105

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions text/0096-rename-tasks-evaluations-hooks.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
# Group Keptn Tasks and Evaluations as Hooks

Proposal to change the way the project refers to Keptn Tasks and Evaluations. Instead, refer to both as Keptn Hooks.

## Motivation

* Make it simpler for a user to understand the core concepts of Keptn Lifecycle Toolkit

## 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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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.


Instead we start referring to Keptn hooks. Keptn hooks are a way to interject into the lifecycle of a running Keptn process.

With this description, the explanation becomes easy. There are two possible Keptn hooks:

- Evaluations
- Tasks

Keptn hooks can be configured to fire at any of these times:

- Pre-deployment at a workload level
- Pre-deployment at an application level
- Pre-deployment at a workload level
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean "Post-deployment at a workload level" here?

- Post-deployment at a workload level
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!


## Internal details

Note: This KEP does not mean changing anything about the current implementation: KeptnTasks and KeptnEvaluations remain as-is.

This is simply a way to all agree on how we message and refer to these capabilities.

Ergo, no additional coding is expected (apart from documentation rewording).

## Trade-offs and mitigations


## Breaking changes

None

## Prior art and alternatives


## Open questions

## Future possibilities