docs: unify styling of implementing folder (keptn#2398)

docs/content/en/contribute/software/dev-environ/_index.md

@@ -57,7 +57,7 @@ you also see the `runtimes` directory.
 This defines the runners that you can use when defining
 tasks to be run either pre- or post-deployment.
 These are discussed in
-[Runners and containers](../../../docs/implementing/tasks/#runners-and-containers).
+[Runners and containers](../../../docs/implementing/tasks.md#runners-and-containers).
 
 ## Install software
 

docs/content/en/docs/architecture/components/metrics-operator.md

@@ -27,7 +27,7 @@ so they are compatible with the Kubernetes
 (HPA), which enables the horizontal scaling of workloads
 based on metrics collected from multiple observability platforms.
 See
-[Using the HorizontalPodAutoscaler](../../implementing/evaluatemetrics.md/#using-the-horizontalpodautoscaler)
+[Using the HorizontalPodAutoscaler](../../implementing/evaluatemetrics.md#using-the-horizontalpodautoscaler)
 for instructions.
 
 The Metrics Operator consists of the following components:

docs/content/en/docs/architecture/components/scheduler.md

@@ -23,7 +23,7 @@ to gate Pods until the required deployment checks pass.
 When you apply a workload to a K8s cluster,
 the Mutating Webhook checks each Pod for annotations
 to see if it is annotated with
-[Keptn specific annotations](../../implementing/integrate/_index.md#basic-annotations).
+[Keptn specific annotations](../../implementing/integrate.md#basic-annotations).
 If the annotations are present, the Webhook adds a gate to the Pod called `keptn-prechecks-gate`.
 This spec tells the Kubernetes scheduling framework
 to wait for  the Keptn checks before assigning the pod to a node.
@@ -64,7 +64,7 @@ a [Permit plugin](https://kubernetes.io/docs/concepts/scheduling-eviction/schedu
 ### How does the Keptn Scheduler works
 
 Firstly the Mutating Webhook checks for annotations on Pods to see if it is annotated with
-[Keptn specific annotations](../../implementing/integrate/#basic-annotations).
+[Keptn specific annotations](../../implementing/integrate.md#basic-annotations).
 If the annotations are present, the Webhook assigns the **Keptn Scheduler** to the Pod.
 This ensures that the Keptn Scheduler only gets Pods that have been annotated for it.
 A Pod `test-pod` modified by the Mutating Webhook looks as follows:

docs/content/en/docs/architecture/keptn-apps.md

@@ -64,12 +64,12 @@ plus specific tasks and evaluations that you define
 for the `KeptnApp` resource itself:
 
 * The annotations described in
-  [Basic annotations](../implementing/integrate/#basic-annotations)
+  [Basic annotations](../implementing/integrate.md#basic-annotations)
   are used to automatically generate `KeptnApp` resources
   that contain the identifications required
   to run the Keptn observability features.
 * You must manually add the annotations described in
-  [Pre- and post-deployment checks](../implementing/integrate/#pre--and-post-deployment-checks)
+  [Pre- and post-deployment checks](../implementing/integrate.md#pre--and-post-deployment-checks)
   to the basic `KeptnApp` manifest to define
   the evaluations and tasks you want to run pre- and post-deployment.
 
@@ -91,7 +91,7 @@ resource.
 
 ## How basic annotations are implemented
 
-The [Basic annotations](../implementing/integrate/#basic-annotations)
+The [Basic annotations](../implementing/integrate.md#basic-annotations)
 page gives instructions for applying the annotations or labels
 that identify the pods that Keptn should manage.
 

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

@@ -23,7 +23,7 @@ When Keptn is successfully monitoring your deployments, it can also run arbitrar
 - post-deployment (after the post is scheduled)
 
 > Pre and post deployments can also run on a KeptnApp level.
-> See [annotations to KeptnApp](../implementing/integrate/_index.md#annotations-to-keptnapp)
+> See [annotations to KeptnApp](../implementing/integrate.md#annotations-to-keptnapp)
 
 ## Prerequisites: Deploy webhook sink
 
@@ -219,7 +219,7 @@ Do this by using the `keptn.sh/pre-deployment-tasks` label.
 ## Further Information
 
 There is a lot more you can do with KeptnTasks.
-See [pre and post deployment checks page](../implementing/integrate#pre--and-post-deployment-checks) to find out more.
+See [pre and post deployment checks page](../implementing/integrate.md#pre--and-post-deployment-checks) to find out more.
 
 ## What's next?
 

docs/content/en/docs/getting-started/observability.md

@@ -525,7 +525,7 @@ spec:
     that failed to deploy, perhaps because a
     `preDeploymentEvaluation` or `preDeploymentTask` failed.
     See
-    [Restart an Application Deployment](../implementing/restart-application-deployment/)
+    [Restart an Application Deployment](../implementing/restart-application-deployment.md)
     for a longer discussion of this.
   - **workloads**
     - **name** - name of this Kubernetes
@@ -595,4 +595,4 @@ See [KeptnApp Reference page](../yaml-crd-ref/app.md) for more information.
 
 Keptn can run pre and post deployment tasks and SLO evaluations automatically.
 
-Continue the Keptn learning journey by [adding deployment tasks](../implementing/tasks).
+Continue the Keptn learning journey by [adding deployment tasks](../implementing/tasks.md).

docs/content/en/docs/implementing/day-2-operations/_index.md → docs/content/en/docs/implementing/day-2-operations.md

@@ -5,19 +5,19 @@ weight: 500
 ---
 
 After you have successfully rolled out your application by following
-the instructions in the [integration guide](../integrate),
+the instructions in the [integration guide](./integrate.md),
 Keptn also assists you with day 2 operations for your application.
 
 Tasks that fall under this category include:
 
 * Updating the version of one or more [workloads](https://kubernetes.io/docs/concepts/workloads/)
 that are part of the same application
 * Adding a new [workload](https://kubernetes.io/docs/concepts/workloads/) to an existing application
-* Monitoring the health of your application using `KeptnMetrics`, as described [here](../evaluatemetrics.md)
+* Monitoring the health of your application using `KeptnMetrics`, as described [here](./evaluatemetrics.md)
 * Optimizing the resource usage of your applications by integrating
 `KeptnMetrics` into a
 [HorizontalPodAutoscaler (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/),
-as described [here](../evaluatemetrics.md/#using-the-horizontalpodautoscaler)
+as described [here](./evaluatemetrics.md/#using-the-horizontalpodautoscaler)
 
 ## Updating Workload Versions
 
@@ -46,7 +46,7 @@ let's assume the following example, including
 a [workload](https://kubernetes.io/docs/concepts/workloads/) called `podtato-head-frontend` that includes a pre-task and
 a pre-evaluation.
 
-{{< embed path="/docs/content/en/docs/implementing/day-2-operations/assets/deployment-initial.yaml" >}}
+{{< docsembed path="content/en/docs/implementing/assets/deployment-initial.yaml" >}}
 
 Now, let's assume that the configuration of that [workload](https://kubernetes.io/docs/concepts/workloads/) needs to be changed.
 In this example we assume that the image of that [workload](https://kubernetes.io/docs/concepts/workloads/)
@@ -59,7 +59,7 @@ of the result of any task or evaluation, e.g., when the previously used image ha
 and the image must be updated as quickly as possible.
 To do that, change `podtato-head-frontend` as follows:
 
-{{< embed path="/docs/content/en/docs/implementing/day-2-operations/assets/deployment-new-image.yaml" >}}
+{{< docsembed path="content/en/docs/implementing/assets/deployment-new-image.yaml" >}}
 
 * **Update the configuration *and* the version label:**
 Doing so causes the `KeptnWorkload` that is associated
@@ -68,7 +68,7 @@ and therefore the pre-task `my-task` and pre-evaluation `my-evaluation`
 are executed before the updated pods are scheduled.
 In this case, the deployment should be changed as follows:
 
-{{< embed path="/docs/content/en/docs/implementing/day-2-operations/assets/deployment-new-image-and-version.yaml" >}}
+{{< docsembed path="content/en/docs/implementing/assets/deployment-new-image-and-version.yaml" >}}
 
 If you have defined the related `KeptnApp` resource yourself,
 this must also be updated to refer to the updated `KeptnWorkload`.
@@ -77,14 +77,14 @@ this updated deployment is not able to progress otherwise.
 Therefore, make sure that the version of `podtato-head-frontend`
 is updated accordingly:
 
-{{< embed path="/docs/content/en/docs/implementing/day-2-operations/assets/app-updated-version.yaml" >}}
+{{< docsembed path="content/en/docs/implementing/assets/app-updated-version.yaml" >}}
 
 Updating the `KeptnApp` also causes all pre-/post-tasks/evaluations
 of the `KeptnApp` to be executed again.
 In this example, this means that the tasks `wait-for-prometheus`,
 and `post-deployment-loadtests` will run again.
 
-If you are using the [automatic app discovery](../integrate#use-keptn-automatic-app-discovery),
+If you are using the [automatic app discovery](./integrate.md#use-keptn-automatic-app-discovery),
 you do not need to update the `KeptnApp` resource.
 Keptn will take care of that for you.
 
@@ -133,7 +133,7 @@ For example, to add the deployment `podtato-head-left-leg` to the
 `podtato-head` application, the configuration for that new deployment
 would look like this, with the required label being set:
 
-{{< embed path="/docs/content/en/docs/implementing/day-2-operations/assets/new-deployment.yaml" >}}
+{{< docsembed path="content/en/docs/implementing/assets/new-deployment.yaml" >}}
 
 The `KeptnApp`, if defined by the user, should contain the
 reference to the newly added [workload](https://kubernetes.io/docs/concepts/workloads/).
@@ -142,7 +142,7 @@ progress if it is not part of a `KeptnApp`.
 For automatically discovered apps this is done
 automatically.
 
-{{< embed path="/docs/content/en/docs/implementing/day-2-operations/assets/app-with-new-workload.yaml" >}}
+{{< docsembed path="content/en/docs/implementing/assets/app-with-new-workload.yaml" >}}
 
 After applying the updated manifests, you can monitor the status
 of the application and related [workloads](https://kubernetes.io/docs/concepts/workloads/) using the following commands:

docs/content/en/docs/implementing/dora/_index.md → docs/content/en/docs/implementing/dora.md

@@ -21,7 +21,7 @@ DORA metrics provide information such as:
 
 Keptn starts collecting these metrics
 as soon as you apply
-[basic annotations](../integrate/#basic-annotations)
+[basic annotations](./integrate.md#basic-annotations)
 to the
 [Workload](https://kubernetes.io/docs/concepts/workloads/)
 resources
@@ -59,4 +59,4 @@ DORA metrics are also displayed on Grafana
 or whatever dashboard application you choose.
 For example:
 
-![DORA metrics](assets/dynatrace_dora_dashboard.png)
+![DORA metrics](../assets/dynatrace_dora_dashboard.png)

docs/content/en/docs/implementing/evaluatemetrics.md

@@ -56,7 +56,7 @@ To configure a data provider into your Keptn cluster:
 
 1. Create a secret if your data provider uses one.
    See
-   [Create secret text](../implementing/tasks/#create-secret-text).
+   [Create secret text](./tasks.md#create-secret-text).
 1. Install and configure each instance of each data provider
    into your Keptn cluster,
    following the instructions provided by the data source provider.

docs/content/en/docs/implementing/evaluations.md

@@ -44,7 +44,7 @@ you must:
   pre- and post-deployment evaluations for the `KeptnApp` itself.
 
 See
-[Pre- and post-deployment checks](../implementing/integrate/#pre--and-post-deployment-checks)
+[Pre- and post-deployment checks](./integrate.md#pre--and-post-deployment-checks)
 for details.
 
 Note the following:

docs/content/en/docs/implementing/integrate/_index.md → docs/content/en/docs/implementing/integrate.md

@@ -20,9 +20,9 @@ to identify the workloads of interest.
 To integrate Keptn with your applications:
 
 * You must first
-[install](../../install/install.md)
+[install](../install/install.md)
 and
-[enable](../../install/install.md//#enable-keptn-for-your-cluster)
+[enable](../install/install.md//#enable-keptn-for-your-cluster)
 Keptn.
 * Annotate or label your workloads
 with either Keptn or Kubernetes keys.
@@ -33,9 +33,9 @@ with either Keptn or Kubernetes keys.
     are required only for the Release lifecycle management feature.
 
 Keptn uses these annotations to the Kubernetes workloads to create the
-[KeptnWorkload](../../crd-ref/lifecycle/v1alpha3/#keptnworkload)
+[KeptnWorkload](../crd-ref/lifecycle/v1alpha3/#keptnworkload)
 and
-[KeptnApp](../../yaml-crd-ref/app.md)
+[KeptnApp](../yaml-crd-ref/app.md)
 resources that it uses to provide observability
 and release lifecycle management.
 
@@ -62,9 +62,9 @@ resources in the namespaces where Keptn is enabled.
 If Keptn finds any of these resources and the resource has either
 the `keptn.sh` or the `kubernetes` annotations/labels,
 it creates appropriate
-[KeptnWorkload](../../crd-ref/lifecycle/v1alpha3/#keptnworkload)
+[KeptnWorkload](../crd-ref/lifecycle/v1alpha3/#keptnworkload)
 and
-[KeptnApp](../../yaml-crd-ref/app.md)
+[KeptnApp](../yaml-crd-ref/app.md)
 resources for the version it detects.
 
 The basic keptn.sh keys that can be used for annotations or labels are:
@@ -89,7 +89,7 @@ These keys are defined as:
 
 * `keptn.sh/workload` or `app.kubernetes.io/name`: Determines the name
   of the generated
-  [KeptnWorkload](../../crd-ref/lifecycle/v1alpha3/#keptnworkload)
+  [KeptnWorkload](../crd-ref/lifecycle/v1alpha3/#keptnworkload)
   resource.
 * `keptn.sh/version` or `app.kubernetes.io/version`:
   Determines the version of the `KeptnWorkload`
@@ -104,7 +104,7 @@ These keys are defined as:
    are consolidated into the same `KeptnApp` resource.
 
 Keptn automatically generates appropriate
-[KeptnApp](../../yaml-crd-ref/app.md)
+[KeptnApp](../yaml-crd-ref/app.md)
 resources that are used for observability,
 based on whether the `keptn.sh/app` or `app.kubernetes.io/part-of`
 annotation/label is populated:
@@ -122,7 +122,7 @@ annotation/label is populated:
   but not the combined workloads that constitute your deployed application.
 
 See
-[Keptn Applications and Keptn Workloads](../../architecture/keptn-apps.md)
+[Keptn Applications and Keptn Workloads](../architecture/keptn-apps.md)
 for architectural information about how `KeptnApp` and `KeptnWorkloads`
 are implemented.
 
@@ -173,19 +173,19 @@ that handles pre- and post-deployment evaluations and tasks,
 do the following:
 
 * Define the
-  [KeptnMetric](../../yaml-crd-ref/metric.md)
+  [KeptnMetric](../yaml-crd-ref/metric.md)
   and
-  [KeptnEvaluationDefinition](../../yaml-crd-ref/evaluationdefinition.md)
+  [KeptnEvaluationDefinition](../yaml-crd-ref/evaluationdefinition.md)
   resources for each evaluation you want.
   A `KeptnEvaluationDefinition` compares the value
   of a `KeptnMetric` to the threshold that is specified.
 * You will also need to define the necessary
-  [KeptnMetricsProvider](../../yaml-crd-ref/metricsprovider.md)
+  [KeptnMetricsProvider](../yaml-crd-ref/metricsprovider.md)
   and
   resource for each instance of each data source
   used for the `KeptnEvaluationDefinition` resources you define.
 * Define a
-  [KeptnTaskDefinition](../../yaml-crd-ref/taskdefinition.md)
+  [KeptnTaskDefinition](../yaml-crd-ref/taskdefinition.md)
   resource for each task you want to execute.
   `KeptnTaskDefinition`  resources contain re-usable "functions"
   that can execute before and after the deployment.
@@ -195,7 +195,7 @@ do the following:
   The deployment is kept in a pending state
   until the infrastructure is capable of accepting deployments again.
   See
-  [Working with Keptn tasks](../tasks)
+  [Working with Keptn tasks](./tasks.md)
   for more information.
 * Annotate your [Workloads](https://kubernetes.io/docs/concepts/workloads/)
   [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/),
@@ -205,7 +205,7 @@ do the following:
   to include each evaluation and task you want run
   for specific workloads.
 * Manually edit all
-  [KeptnApp](../../yaml-crd-ref/app.md) resources
+  [KeptnApp](../yaml-crd-ref/app.md) resources
   to specify evaluations and tasks to be run for the `KeptnApp` itself.
 
 ### Annotations to KeptnApp
@@ -228,7 +228,7 @@ keptn.sh/post-deployment-tasks: <`TaskDefinition`-name>
 The value of these annotations corresponds to the name of
 Keptn [resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
 called
-[KeptnTaskDefinition](../../yaml-crd-ref/taskdefinition.md)
+[KeptnTaskDefinition](../yaml-crd-ref/taskdefinition.md)
 resources
 These resources contain re-usable "functions"
 that can execute before and after the deployment.
@@ -350,7 +350,7 @@ you get observability of your application's deployments
 by using the OpenTelemetry tracing features
 that are provided by Keptn:
 
-![Application deployment trace](assets/trace.png)
+![Application deployment trace](../assets/trace.png)
 
 ## Example of pre- and post-deployment actions
 

docs/content/en/docs/implementing/otel.md

@@ -54,7 +54,7 @@ DORA metrics provide information such as:
 
 Keptn starts collecting these metrics
 as soon as you apply
-[basic annotations](integrate/#basic-annotations)
+[basic annotations](./integrate.md#basic-annotations)
 to the [workload](https://kubernetes.io/docs/concepts/workloads/).
 Metrics are collected only for the resources
 that are annotated.
@@ -140,7 +140,7 @@ you must have the following on your cluster:
 To integrate OpenTelemetry into Keptn:
 
 - Apply
-  [basic annotations](../implementing/integrate/#basic-annotations)
+  [basic annotations](./integrate.md#basic-annotations)
   for your `Deployment` resource
   to integrate Keptn into your Kubernetes cluster.
 - To expose OpenTelemetry metrics,

docs/content/en/docs/implementing/restart-application-deployment/_index.md → docs/content/en/docs/implementing/restart-application-deployment.md

@@ -6,11 +6,11 @@ weight: 100
 hidechildren: false # this flag hides all sub-pages in the sidebar-multicard.html
 ---
 
-A [KeptnApp](../../yaml-crd-ref/app.md) can fail
+A [KeptnApp](../yaml-crd-ref/app.md) can fail
 because of an unsuccessful pre-deployment evaluation
 or pre-deployment task.
 For example, this happens if the target value of a
-[KeptnEvaluationDefinition](../../yaml-crd-ref/evaluationdefinition.md)
+[KeptnEvaluationDefinition](../yaml-crd-ref/evaluationdefinition.md)
 resource is misconfigured
 or a pre-deployment evaluation checks the wrong URL.