Merge branch 'main' into chainsaw-migrate

docs/blog/posts/2023-keptn-year-in-review.md

@@ -10,8 +10,7 @@ comments: true
 
 Hello and Happy New Year from the entire Keptn Team.
 We hope you had a wonderful holiday season and that you’re all having a wonderful 2024 so far!
-We’d like to take a moment to reflect back on what a great year 2023 was for Keptn and all the
-road ahead for this year.
+We’d like to take a moment to reflect back on what a great year 2023 was for Keptn and what we're looking forward to in 2024!
 
 The biggest news for the project in 2023 was probably the maturing of the cloud native Keptn,
 with the former subproject named Keptn Lifecycle Toolkit officially becoming Keptn in August 2023,

docs/docs/getting-started/assets/keptnappcontext.yaml

@@ -0,0 +1,8 @@
+apiVersion: lifecycle.keptn.sh/v1beta1
+kind: KeptnAppContext
+metadata:
+  name: keptndemoapp
+  namespace: keptndemo
+spec:
+  postDeploymentTasks:
+    - send-event

docs/docs/getting-started/lifecycle-management.md

@@ -33,7 +33,7 @@ and
 
 > Pre and post deployments can be run either on individual workloads
 > or on a group of associated workloads that are grouped into
-> a`KeptnApp` resource.
+> a `KeptnApp` resource.
 > For instructions about how to identify the workloads to combine into  `KeptnApp` resource,
 > see
 > [annotations to KeptnApp](../guides/integrate.md#basic-annotations).
@@ -100,7 +100,7 @@ Apply this manifest:
 
 ```yaml
 ---
-apiVersion: lifecycle.keptn.sh/v1alpha3
+apiVersion: lifecycle.keptn.sh/v1beta1
 kind: KeptnTaskDefinition
 metadata:
   name: send-event
@@ -135,7 +135,7 @@ Apply this manifest:
 
 ```yaml
 ---
-apiVersion: lifecycle.keptn.sh/v1alpha3
+apiVersion: lifecycle.keptn.sh/v1beta1
 kind: KeptnTask
 metadata:
   name: runsendevent1
@@ -249,6 +249,27 @@ Do this by using the `keptn.sh/pre-deployment-tasks` label or annotation.
 
 > Note: If a pre-deployment task fails, the `Pod` remains in a Pending state.
 
+## More control over the application
+
+To customize checks associated with the application, we can create a `KeptnAppContext` resource and define
+a set of pre/post deployment tasks or evaluations for the whole application.
+Note that the name of the `KeptnAppContext` resource needs to match the name of the automatically
+created `KeptnApp` and the value present in the `keptn.sh/app` or `app.kubernetes.io/part-of`
+annotations.
+In this case it needs to be `keptndemoapp`.
+An example of `KeptnAppContext`:
+
+```yaml
+{% include "./assets/keptnappcontext.yaml" %}
+```
+
+This way, the `send-event` task is executed after the deployment of the whole application;
+in other words, after all of the workloads present in the `KeptnApp`
+are in a `Running` state.
+
+A detailed description of all the available fields of the `KeptnAppContext` resource can be found in the
+[KeptnAppContext API reference page](../reference/api-reference/lifecycle/v1beta1/index.md#keptnappcontext).
+
 ## Further Information
 
 You can do much more with `KeptnTask` resources.

docs/docs/getting-started/observability.md

@@ -474,123 +474,6 @@ View the Keptn Applications Dashboard and you should see the DORA metrics and an
 
 ![deployment trace](./assets/deploymenttrace.png)
 
-## Step 14: More control over KeptnApp
-
-To customize workloads and checks associated with the application, we can edit the autogenerated KeptnApp or create our own.
-
-```yaml
-apiVersion: lifecycle.keptn.sh/v1alpha3
-kind: KeptnApp
-metadata:
-  name: <app-name>
-  namespace: <app-namespace>
-spec:
-  version: "x.y"
-  revision: x
-  workloads:
-  - name: <workload1-name>
-    version: <version-string>
-  - name: <workload2-name>
-    version: <version-string>
-  preDeploymentTasks:
-  - <list of tasks>
-  postDeploymentTasks:
-  - <list of tasks>
-  preDeploymentEvaluations:
-  - <list of evaluations>
-  postDeploymentEvaluations:
-  - <list of evaluations>
-```
-
-## Fields
-
-- **apiVersion** -- API version being used.
-- **kind** -- Resource type.
-   Must be set to `KeptnApp`
-
-- **metadata**
-  - **name** -- Unique name of this application.
-    Names must comply with the
-    [Kubernetes Object Names and IDs](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)
-    specification.
-
-- **spec**
-  - **version** -- version of the Keptn application.
-    Changing this version number causes a new execution
-    of all application-level checks
-  - **revision** -- revision of a `version`.
-    The value is an integer that can be modified
-    to trigger another deployment of a `KeptnApp` of the same version.
-    For example, increment this number to restart a `KeptnApp` version
-    that failed to deploy, perhaps because a
-    `preDeploymentEvaluation` or `preDeploymentTask` failed.
-    See
-    [Restart an Application Deployment](../guides/restart-application-deployment.md)
-    for a longer discussion of this.
-  - **workloads**
-    - **name** - name of this Kubernetes
-      [workload](https://kubernetes.io/docs/concepts/workloads/).
-      Use the same naming rules listed above for the application name.
-      Provide one entry for each workload
-      associated with this Keptn application.
-    - **version** -- version number for this workload.
-      Changing this number causes a new execution
-      of checks for this workload only,
-      not the entire application.
-
-The remaining fields are required only when implementing
-the release lifecycle management feature.
-If used, these fields must be populated manually:
-
-- **preDeploymentTasks** -- list each task
-    to be run as part of the pre-deployment stage.
-    Task names must match the value of the `metadata.name` field
-    for the associated [KeptnTaskDefinition](../reference/crd-reference/taskdefinition.md) resource.
-- **postDeploymentTasks** -- list each task
-    to be run as part of the post-deployment stage.
-    Task names must match the value of the `metadata.name` field
-    for the associated
-    [KeptnTaskDefinition](../reference/crd-reference/taskdefinition.md)
-    resource.
-- **preDeploymentEvaluations** -- list each evaluation to be run
-    as part of the pre-deployment stage.
-    Evaluation names must match the value of the `metadata.name` field
-    for the associated
-    [KeptnEvaluationDefinition](../reference/crd-reference/evaluationdefinition.md)
-    resource.
-- **postDeploymentEvaluations** -- list each evaluation to be run
-    as part of the post-deployment stage.
-    Evaluation names must match the value of the `metadata.name` field
-    for the associated [KeptnEvaluationDefinition](../reference/crd-reference/evaluationdefinition.md)
-    resource.
-
-## Example
-
-```yaml
-apiVersion: lifecycle.keptn.sh/v1alpha3
-kind: KeptnApp
-metadata:
-  name: podtato-head
-  namespace: podtato-kubectl
-spec:
-  version: "latest"
-  workloads:
-  - name: podtato-head-left-arm
-    version: "my_vers12.5"
-  - name: podtato-head-left-leg
-    version: "my_v24"
-  postDeploymentTasks:
-  - post-deployment-hello
-  preDeploymentEvaluations:
-  - my-prometheus-definition
-```
-
-You may have noticed that the `KeptnApp` Custom Resources are created automatically by Keptn.
-
-However, you can override this automatic behaviour by creating a custom `KeptnApp` CRD.
-In this way, you are in full control of what constitutes a Keptn Application.
-See [KeptnApp Reference page](../reference/crd-reference/app.md) for more information.
-
 ## What's next?
 
 Keptn can run pre and post deployment tasks and SLO evaluations automatically.

docs/docs/guides/tasks.md

@@ -199,23 +199,31 @@ page.
 
 ## Context
 
-A Kubernetes context is a set of access parameters
-that contains a Kubernetes cluster, a user, a namespace,
-the application name, workload name, and version.
+The Keptn task context includes details like the application name, version, and object type.
+Keptn uses this when orchestrating automated tasks during deployments, providing a specialized focus on
+the task at hand.
+This information pinpoints the specific application or workload involved, acting as a task-specific blueprint.
+It ensures that Keptn knows precisely where and how to execute each step within your chosen Kubernetes environment.
+Imagine it as a task-specific guide, instructing Keptn on what to do and where to do it within your broader
+deployment workflow.
+
+This contrasts with the Kubernetes context, which is a set of access parameters that defines the
+specific cluster, user and namespace with which you interact.
+It serves as your personalized key to different areas within your Kubernetes infrastructure.
 For more information, see
 [Configure Access to Multiple Clusters](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
 
-You may need to include context information in the `function` code
-included in the YAML file that defines a
+Sometimes, to provide this crucial task context,
+you may need to embed it directly into the `function` code of your
+Keptn tasks defined in YAML files to define a
 [KeptnTaskDefinition](../reference/crd-reference/taskdefinition.md)
 resource.
-For an example of how to do this, see the
-[keptn-tasks.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/keptn-tasks.yaml)
-file.
+The [keptn-tasks.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/keptn-tasks.yaml)
+file offers a practical example of how this works.
 
 A context environment variable is available via `Deno.env.get("KEPTN_CONTEXT")`.
 It can be used like this:
-  
+
 ```javascript
 let context = Deno.env.get("KEPTN_CONTEXT");
     

docs/docs/installation/configuration/namespace.md

@@ -18,7 +18,6 @@ Some considerations for Keptn:
   [Workload](https://kubernetes.io/docs/concepts/workloads/)
   resources and
   [KeptnApp](../../reference/crd-reference/app.md)
-  [KeptnApp](../../reference/crd-reference/app.md)
   resources
   that are activated and defined by annotations to each workload.
 * [KeptnMetricsProvider](../../reference/crd-reference/metricsprovider.md)

docs/docs/migrate/keptnapp/assets/keptnapp-migrated.yaml

@@ -11,7 +11,7 @@ spec:
   workloads:
     - name: podtato-head-left-arm
       version: 0.2.7
-  # removed pre/post-deployment tasks and evaluations
+# removed pre/post-deployment tasks and evaluations
 ---
 apiVersion: lifecycle.keptn.sh/v1beta1
 kind: KeptnAppContext

docs/docs/reference/crd-reference/taskdefinition.md

@@ -149,7 +149,7 @@ spec:
   * **container** -- Container definition.
     * **name** -- Name of the container that will run,
       which is not the same as the `metadata.name` field
-      that is used in the `KeptnApp` resource.
+      that is used in the `KeptnTaskDefinition` resource.
     * **image** -- name of the image you defined according to
       [image reference](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#image)
       and
@@ -270,8 +270,9 @@ spec:
       possibly with different parameters
       that are set in the calling `KeptnTaskDefinition` resource.
 
-      You must annotate the `KeptnApp` resource to run the
-      calling `KeptnTaskDefinition` resource.
+      To be able to run the pre/post-deployment task, you must create
+      the `KeptnAppContext` resource and link the `KeptnTaskDefinition`
+      in the pre/post-deployment section of `KeptnAppContext`.
 
       The `KeptnTaskDefinition` called with `functionref`
       is the `parent task` whose runner is used for the execution

examples/support/observability/config/otel-collector.yaml

@@ -27,7 +27,7 @@ data:
       health_check: {}
     exporters:
       otlp:
-        endpoint: "jaeger-collector:14250"
+        endpoint: "jaeger-collector:4317"
         tls:
           insecure: true
       prometheus:
@@ -103,7 +103,7 @@ spec:
           env:
             - name: GOGC
               value: "80"
-          image: otel/opentelemetry-collector:0.92.0
+          image: otel/opentelemetry-collector:0.93.0
           name: otel-collector
           resources:
             limits: