fix: broken links (#110)

Author: vknabel

docs/contributing/01-Proposals/MEP18/README.md

@@ -6,7 +6,7 @@ sidebar_position: 18
 
 # Autonomous Control Plane
 
-As described in the [deployment chapter](../../../docs/04-For%20Operators/03-deployment-guide.md), we strongly recommend Kubernetes as the target platform for running the metal-stack control plane.
+As described in the [deployment chapter](../../../docs/04-For%20Operators/03-deployment-guide.mdx), we strongly recommend Kubernetes as the target platform for running the metal-stack control plane.
 
 Kubernetes clusters for this purpose are readily available from hyperscalers, metalstack.cloud, or other cloud providers. Simply using a managed Kubernetes cluster greatly simplifies a metal-stack installation. However, sometimes it might be desirable to host the metal-stack control plane autonomously, without the help of another cloud provider. Reasons for this might include corporate policies that prohibit the use of external data center products, or network constraints.
 

docs/contributing/03-contribution-guideline.md

@@ -21,7 +21,7 @@ Open a Github issue in the project you would like to contribute. Within the issu
 When opening an issue please consider the following aspects:
 
 1. Create a meaningful issue describing the WHY? of your contribution.
-1. Try to set appropriate labels to the issue. For example, attach the `triage` label to your issue if you want it to be discussed in the next [planning meeting](./02-planning-meetings.md). It might be useful to attend the meeting if you want to emphasize it being worked on.
+1. Try to set appropriate labels to the issue. For example, attach the `triage` label to your issue if you want it to be discussed in the next [planning meeting](./02-planning-meetings.mdx). It might be useful to attend the meeting if you want to emphasize it being worked on.
 
 ### Pull Requests
 
@@ -125,7 +125,7 @@ We want to share knowledge and keep things simple. If things cannot kept simple
 
 - Document in short sentences[^4].
 - Do not explain the HOW (this is already documented by your code and documenting the obvious is considered a defect).
-- Explain the WHY. Add a "to" in your documentation line to force yourself to explain the reasonning (e.g.  "`<THE WHAT> to <THE TO>`").
+- Explain the WHY. Add a "to" in your documentation line to force yourself to explain the reasonning (e.g. "`<THE WHAT> to <THE TO>`").
 
 ### Python
 
@@ -137,7 +137,11 @@ Development follows the official guide to:
 - If you want to add a Python microservice to the mix, consider [pyinstaller](https://github.com/pyinstaller/pyinstaller) on Alpine to achieve small image sizes
 
 [^1]: [https://martinfowler.com/bliki/CodeOwnership.html](https://martinfowler.com/bliki/CodeOwnership.html)
+
 [^2]: [https://go.dev/doc/effective_go](https://go.dev/doc/effective_go)
+
 [^3]: [https://github.com/golang/go/wiki/CodeReviewComments](https://github.com/golang/go/wiki/CodeReviewComments)
+
 [^4]: [https://github.com/golang/go/wiki/CodeReviewComments#comment-sentences](https://github.com/golang/go/wiki/CodeReviewComments#comment-sentences)
+
 [^5]: [https://www.python.org/dev/peps/pep-0008/](https://www.python.org/dev/peps/pep-0008/)

docs/docs/04-For Operators/02-operating-systems.md

@@ -32,7 +32,7 @@ The supported images for firewalls are:
 
 It is fully possible to build your own operating system images and provide them through the metal-stack.
 
-There are some conventions though that you need to follow in order to make your image installable through the metal-hammer. You should understand the [machine provisioning sequence](../05-Concepts/01-architecture.md#machine-provisioning-sequence) before starting to write your own images.
+There are some conventions though that you need to follow in order to make your image installable through the metal-hammer. You should understand the [machine provisioning sequence](../05-Concepts/01-architecture.mdx#machine-provisioning-sequence) before starting to write your own images.
 
 1. Images need to be compressed to a tarball using the [lz4](https://de.wikipedia.org/wiki/LZ4) compression algorithm.
 1. An `md5` checksum file with the same name as the image archive needs to be provided in the download path along with the actual os image.

docs/docs/04-For Operators/03-deployment-guide.mdx

@@ -3,9 +3,10 @@ slug: /deployment-guide
 title: Deployment Guide
 sidebar_position: 3
 ---
+
 # Deployment Guide
 
-We are bootstrapping the [metal control plane](../05-Concepts/01-architecture.md#metal-control-plane) as well as our [partitions](../05-Concepts/01-architecture.md#partitions) with [Ansible](https://www.ansible.com/) through CI.
+We are bootstrapping the [metal control plane](../05-Concepts/01-architecture.mdx#metal-control-plane) as well as our [partitions](../05-Concepts/01-architecture.mdx#partitions) with [Ansible](https://www.ansible.com/) through CI.
 
 In order to build up your deployment, we recommend to make use of the same Ansible roles that we are using by ourselves in order to deploy the metal-stack. You can find them in the repository called [metal-roles](https://github.com/metal-stack/metal-roles).
 
@@ -30,7 +31,7 @@ You can use the [mini-lab](https://github.com/metal-stack/mini-lab) as a templat
 The metal control plane is typically deployed in a Kubernetes cluster. Therefore, this document will assume that you have a Kubernetes cluster ready for getting deployed. Even though it is theoretically possible to deploy metal-stack without Kubernetes, we strongly advise you to use the described method because we believe that Kubernetes gives you a lot of benefits regarding the stability and maintainability of the application deployment.
 
 :::tip
-For metal-stack it does not matter where your control plane Kubernetes cluster is located. You can of course use a cluster managed by a hyperscaler. This has the advantage of not having to setup Kubernetes by yourself and could even become beneficial in terms of fail-safe operation. However, we also describe a solution of how to setup metal-stack with a self-hosted, [Autonomous Control Plane](../../contributing/01-Proposals/MEP18/README.md) cluster. The only requirement from metal-stack is that your partitions can establish network connections to the metal control plane. If you are interested, you can find a reasoning behind this deployment decision [here](../05-Concepts/01-architecture.md#target-deployment-platforms).
+For metal-stack it does not matter where your control plane Kubernetes cluster is located. You can of course use a cluster managed by a hyperscaler. This has the advantage of not having to setup Kubernetes by yourself and could even become beneficial in terms of fail-safe operation. However, we also describe a solution of how to setup metal-stack with a self-hosted, [Autonomous Control Plane](../../contributing/01-Proposals/MEP18/README.md) cluster. The only requirement from metal-stack is that your partitions can establish network connections to the metal control plane. If you are interested, you can find a reasoning behind this deployment decision [here](../05-Concepts/01-architecture.mdx#target-deployment-platforms).
 :::
 
 Let's start off with a fresh folder for your deployment:
@@ -77,10 +78,10 @@ You can already define the `inventories/group_vars/all/images.yaml` file. It con
 import CodeBlock from '@theme/CodeBlock';
 import latestRelease from '@site/src/version.json'
 export function ImageReleaseConfig() {
-  return <><CodeBlock language="yaml">
-            ---{"\n"}
-            metal_stack_release_version: {latestRelease.version}
-          </CodeBlock></>
+return <><CodeBlock language="yaml">
+---{"\n"}
+metal_stack_release_version: {latestRelease.version}
+</CodeBlock></>
 }
 
 <ImageReleaseConfig />
@@ -232,7 +233,7 @@ metal_control_plane_ingress_dns: <your-dns-domain> # if you do not have a DNS en
 
 We have several components in our stack that communicate over encrypted gRPC just like Kubernetes components do.
 
-For the very basic setup you will need to create self-signed certificates for the communication between the following components (see [architecture](../05-Concepts/01-architecture.md) document):
+For the very basic setup you will need to create self-signed certificates for the communication between the following components (see [architecture](../05-Concepts/01-architecture.mdx) document):
 
 - [metal-api](https://github.com/metal-stack/metal-api) and [masterdata-api](https://github.com/metal-stack/masterdata-api) (in-cluster traffic communication)
 - [metal-api](https://github.com/metal-stack/metal-api) and [metal-hammer](https://github.com/metal-stack/metal-hammer) (partition to control plane communication)
@@ -448,15 +449,16 @@ For the actual communication between the metal-api and the user clients (REST AP
 Finally, it should be possible to run the deployment through a Docker container. Make sure to have the [Kubeconfig file](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) of your cluster and set the path in the following command accordingly:
 
 export function VariableConfig() {
-  return <><CodeBlock language="bash">
-              export KUBECONFIG={"\<"}path-to-your-cluster-kubeconfig{"\>"}{"\n"}
-              export METAL_VERSION={latestRelease.version}
-          </CodeBlock></>
+return <><CodeBlock language="bash">
+export KUBECONFIG={"\<"}path-to-your-cluster-kubeconfig{"\>"}{"\n"}
+export METAL_VERSION={latestRelease.version}
+</CodeBlock></>
 }
 
 <VariableConfig />
 
 Then you can spin up the deployment with docker:
+
 ```bash
 docker run --rm -it \
   -v $(pwd):/workdir \
@@ -552,21 +554,21 @@ If you decided to use OIDC, you can parametrize the [metal role](https://github.
 ```yaml
 ---
 metal_masterdata_api_tenants:
-- meta:
-    id: <id>
-    kind: Tenant
-    apiversion: v1
-    version: 0
-  name: <name>
-  iam_config:
-    issuer_config:
+  - meta:
+      id: <id>
+      kind: Tenant
+      apiversion: v1
+      version: 0
+    name: <name>
+    iam_config:
+      issuer_config:
         client_id: <client_id>
         url: <oidc_url>
-    idm_config:
-      idm_type: <type> # "AD" | "UX"
-    group_config:
-      namespace_max_length: 20
-  description: <description>
+      idm_config:
+        idm_type: <type> # "AD" | "UX"
+      group_config:
+        namespace_max_length: 20
+    description: <description>
 ```
 
 ## Bootstrapping a Partition

docs/docs/05-Concepts/04-Kubernetes/01-gardener.md

@@ -59,7 +59,7 @@ Every Kubernetes cluster that is fully provisioned and managed by Gardener is ca
 
 During the provisioning flow of a cluster, Gardener emits resources that are expected to be reconciled by controllers of a cloud provider. This section briefly describes the controllers implemented by metal-stack to allow the creation of a Kubernetes cluster on metal-stack infrastructure.
 
-If you want to learn how to deploy metal-stack with Gardener, please check out the corresponding [deployment-guide section](../../04-For%20Operators/03-deployment-guide.md#gardener-with-metal-stack).
+If you want to learn how to deploy metal-stack with Gardener, please check out the corresponding [deployment-guide section](../../04-For%20Operators/03-deployment-guide.mdx#gardener-with-metal-stack).
 
 ### gardener-extension-provider-metal
 
@@ -93,9 +93,9 @@ Some suggestions for the initial K8s cluster are:
 
 Suggestions for default values are:
 
-  - `gcp_machine_type`: e2-standard-8
-  - `gcp_autoscaling_min_nodes`: 1
-  - `gcp_autoscaling_max_nodes`: 3
+- `gcp_machine_type`: e2-standard-8
+- `gcp_autoscaling_min_nodes`: 1
+- `gcp_autoscaling_max_nodes`: 3
 
 ### Initial Cluster on metalstack.cloud
 
@@ -118,13 +118,13 @@ After setting up the initial K8s cluster and metal-stack, Gardener can be deploy
 
 This deploys the following components:
 
-  - virtual garden
-  - Gardener control plane components
-  - soil cluster
-  - managed seed cluster (into the metal-stack partition)
+- virtual garden
+- Gardener control plane components
+- soil cluster
+- managed seed cluster (into the metal-stack partition)
 
 In summary, this results in the following:
 
- - `Garden cluster` created in the initial cluster
- - `soil cluster` created in the initial cluster. This will be the `initial seed` used for spinning up `shooted seeds` in the metal-stack partition
- - `shooted seed` inside the metal-stack partition, where all `shoots` are derived from
+- `Garden cluster` created in the initial cluster
+- `soil cluster` created in the initial cluster. This will be the `initial seed` used for spinning up `shooted seeds` in the metal-stack partition
+- `shooted seed` inside the metal-stack partition, where all `shoots` are derived from

docs/docs/06-For CISOs/Security/03-cryptography.md

@@ -10,7 +10,7 @@ metal-stack incorporates multiple layers of cryptographic protection and secure
 
 ### TLS Certificate Management
 
-TLS certificates used by metal-stack components - as outlined in the [architecture section](../../05-Concepts/01-architecture.md) - can be generated using either RSA 4096-bit or ECDSA 256-bit keys. We recommend RSA 4096.
+TLS certificates used by metal-stack components - as outlined in the [architecture section](../../05-Concepts/01-architecture.mdx) - can be generated using either RSA 4096-bit or ECDSA 256-bit keys. We recommend RSA 4096.
 
 By default, in-cluster communication is not encrypted. If encryption is required within the cluster, it must be configured manually using a service mesh (e.g., Istio or Linkerd) or a similar mechanism.
 For outbound traffic, we recommend integrating cert-manager in combination with Let's Encrypt to handle certificate issuance and enable automated certificate rotation for ingress domains. In offline environments where Let's Encrypt cannot be used, the certificates must be issued and managed manually or via an internal CA.

docs/docs/08-References/Storage/duros-controller/MULTITENANCY.md

@@ -20,7 +20,7 @@ Multi tenancy in metal-stack and gardener are based on projects. In metal-stack,
 
 Lightbits storage has also the notion of a project, once a cluster is created, a new project is created in the lightos storage API, the project there matches the project from the gardener/metal-stack perspective. For every cluster an authentication token in the JWT format is created, this token is able to create/update/list/delete volumes in the lightos cluster in the given project, resp. lightos project. For every kubernetes cluster, even in the same project, an individual JWT token is created. The token is also set to have a 8 day validity, 1 day before the token will get invalid and the cluster still exists, a new token is issued.
 
-The duros-controller is responsible to create such tokens, it is deployed in the seed's shoot namespace (find details on gardener architecture [here](../../../05-Concepts/01-architecture.md)). This namespace is fully managed by the provider and invisible for the cluster user. Once the token has been created, the token is stored in a secret in the actual user cluster alongside with the deployment of the lightbits CSI driver and storage classes. This CSI driver will then be responsible to create/update/delete volumes based on the manifests deployed in the cluster.
+The duros-controller is responsible to create such tokens, it is deployed in the seed's shoot namespace (find details on gardener architecture [here](../../../05-Concepts/01-architecture.mdx)). This namespace is fully managed by the provider and invisible for the cluster user. Once the token has been created, the token is stored in a secret in the actual user cluster alongside with the deployment of the lightbits CSI driver and storage classes. This CSI driver will then be responsible to create/update/delete volumes based on the manifests deployed in the cluster.
 
 ```bash
 k get sc
@@ -79,7 +79,6 @@ metadata:
   namespace: kube-system
   resourceVersion: "1837602"
   uid: 406c3583-d4cd-4a0b-8615-3a6f2b9b7577
-
 ```
 
 ## Lightbits and NVMEoTCP
@@ -126,4 +125,4 @@ nqn.2019-09.com.lightbitslabs:host:shoot--pd76mr--inttest0-group-0-845b8-49r7x.n
 
 ## Further improvements
 
-In the upcoming lightos release the performance aspects of multi tenancy are addressed. This is achieved that it will be possible to cap the maximum throughput possible per volume. This will ensure that no single tenant is able to saturate the whole lightos cluster and impact other tenants using this lightos cluster.
+In the upcoming lightos release the performance aspects of multi tenancy are addressed. This is achieved that it will be possible to cap the maximum throughput possible per volume. This will ensure that no single tenant is able to saturate the whole lightos cluster and impact other tenants using this lightos cluster.

versioned_docs/version-v0.21.10/contributing/01-Proposals/MEP18/README.md

@@ -6,7 +6,7 @@ sidebar_position: 18
 
 # Autonomous Control Plane
 
-As described in the [deployment chapter](../../../docs/04-For%20Operators/03-deployment-guide.md), we strongly recommend Kubernetes as the target platform for running the metal-stack control plane.
+As described in the [deployment chapter](../../../docs/04-For%20Operators/03-deployment-guide.mdx), we strongly recommend Kubernetes as the target platform for running the metal-stack control plane.
 
 Kubernetes clusters for this purpose are readily available from hyperscalers, metalstack.cloud, or other cloud providers. Simply using a managed Kubernetes cluster greatly simplifies a metal-stack installation. However, sometimes it might be desirable to host the metal-stack control plane autonomously, without the help of another cloud provider. Reasons for this might include corporate policies that prohibit the use of external data center products, or network constraints.
 

versioned_docs/version-v0.21.10/contributing/03-contribution-guideline.md

@@ -125,7 +125,7 @@ We want to share knowledge and keep things simple. If things cannot kept simple
 
 - Document in short sentences[^4].
 - Do not explain the HOW (this is already documented by your code and documenting the obvious is considered a defect).
-- Explain the WHY. Add a "to" in your documentation line to force yourself to explain the reasonning (e.g.  "`<THE WHAT> to <THE TO>`").
+- Explain the WHY. Add a "to" in your documentation line to force yourself to explain the reasonning (e.g. "`<THE WHAT> to <THE TO>`").
 
 ### Python
 
@@ -137,7 +137,11 @@ Development follows the official guide to:
 - If you want to add a Python microservice to the mix, consider [pyinstaller](https://github.com/pyinstaller/pyinstaller) on Alpine to achieve small image sizes
 
 [^1]: [https://martinfowler.com/bliki/CodeOwnership.html](https://martinfowler.com/bliki/CodeOwnership.html)
+
 [^2]: [https://go.dev/doc/effective_go](https://go.dev/doc/effective_go)
+
 [^3]: [https://github.com/golang/go/wiki/CodeReviewComments](https://github.com/golang/go/wiki/CodeReviewComments)
+
 [^4]: [https://github.com/golang/go/wiki/CodeReviewComments#comment-sentences](https://github.com/golang/go/wiki/CodeReviewComments#comment-sentences)
+
 [^5]: [https://www.python.org/dev/peps/pep-0008/](https://www.python.org/dev/peps/pep-0008/)

versioned_docs/version-v0.21.10/docs/04-For Operators/02-operating-systems.md

@@ -32,7 +32,7 @@ The supported images for firewalls are:
 
 It is fully possible to build your own operating system images and provide them through the metal-stack.
 
-There are some conventions though that you need to follow in order to make your image installable through the metal-hammer. You should understand the [machine provisioning sequence](../05-Concepts/01-architecture.md#machine-provisioning-sequence) before starting to write your own images.
+There are some conventions though that you need to follow in order to make your image installable through the metal-hammer. You should understand the [machine provisioning sequence](../05-Concepts/01-architecture.mdx#machine-provisioning-sequence) before starting to write your own images.
 
 1. Images need to be compressed to a tarball using the [lz4](https://de.wikipedia.org/wiki/LZ4) compression algorithm.
 1. An `md5` checksum file with the same name as the image archive needs to be provided in the download path along with the actual os image.