Merge branch 'main' into rook

.github/linkspector.yml

@@ -0,0 +1,4 @@
+---
+ignorePatterns:
+  - pattern: "^(?!http(s)?:\/\/.*)|^(http(s)?:\/\/.*((osism.xyz)|(in-a-box.cloud)))(:?[0-9]+)?(\/.*)?$"
+  - pattern: "^https:\/\/www.wireguard.com$"

.github/workflows/check-markdown-links.yml

@@ -0,0 +1,17 @@
+name: Check Markdown links
+on:
+  push:
+
+jobs:
+  check-markdown-links:
+    name: Run linkspector
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Run linkspector
+        uses: umbrelladocs/action-linkspector@v1
+        with:
+          config-file: .github/linkspector.yml
+          github_token: ${{ secrets.github_token }}
+          reporter: github-pr-review
+          fail_on_error: true

docs/appendix/networks.md

@@ -0,0 +1,25 @@
+---
+sidebar_label: Networks
+---
+
+# Networks
+
+| Parameter                          | CIDR                |
+|:-----------------------------------|:--------------------|
+| `cephclient_network`               | `172.31.100.0/28`   |
+| `openstackclient_network`          | `172.31.100.16/28`  |
+| `phpmyadmin_network`               | `172.31.100.32/28`  |
+| `adminer_network`                  | `172.31.100.64/28`  |
+| `openstack_health_monitor_network` | `172.31.100.160/28` |
+| `netbox_network`                   | `172.31.100.176/28` |
+| `homer_network`                    | `172.31.100.208/28` |
+| `manager_network`                  | `172.31.101.0/27`   |
+| `nexus_network`                    | `172.31.101.32/28`  |
+| `dnsdist_network`                  | `172.31.101.80/28`  |
+| `squid_network`                    | `172.31.101.144/28` |
+| `cgit_network`                     | `172.31.101.112/28` |
+| `virtualbmc_network`               | `172.31.101.128/28` |
+| `scaphandre_network`               | `172.31.101.160/28` |
+| `metering_network`                 | `172.31.101.176/28` |
+| `thanos_sidecar_network`           | `172.31.101.192/28` |
+| `traefik_external_network_cidr`    | `172.31.254.0/24`   |

docs/guides/concept-guide/components/index.md

@@ -1 +1,19 @@
+---
+sidebar_label: Components
+sidebar_position: 10
+---
+
 # Components
+
+* [Infrastructure as a Service (IaaS) with OpenStack](./openstack)
+* [Software Defined Storage (SDS) with Ceph](./ceph)
+* [Bare Metal as a Service (BMaaS) with Ironic](./ironic)
+* [Software Defined Networking (SDN) with SONiC & OVN](./sonic)
+* [Kubernetes (K8s) with K3S](./k3s)
+* [Kubernetes as a Service (KaaS) with Gardener](./gardener)
+* [Kubernetes as a Service (KaaS) with Cluster API](./clusterapi)
+* [Identity & Access Management with Keycloak](./keycloak)
+* [Privileged Access Management (PAM) to all infrastructure with Teleport](./teleport)
+* [Logging, Monitoring & Telemetry with Prometheus & Grafana](./prometheus)
+* [Realtime insights with Netdata](./netdata)
+* [Simple virtualization & containerization with Proxmox VE](./proxmox)

docs/guides/concept-guide/components/openstack.md

@@ -13,4 +13,43 @@ in TripleO, the basis for the now discontinued
 [RedHat OpenStack Platform](https://www.redhat.com/en/technologies/linux-platforms/openstack-platform),
 and the [OpenStack Kubernetes Operators](https://github.com/openstack-k8s-operators),
 the basis for the new
-[OpenStack Services on OpenShift from Redhat](https://www.redhat.com/en/blog/red-hat-openstack-services-openshift-next-generation-red-hat-openstack-platform).
+[RedHat OpenStack Services on OpenShift](https://www.redhat.com/en/blog/red-hat-openstack-services-openshift-next-generation-red-hat-openstack-platform).
+
+## OpenStack cluster
+
+![OpenStack cluster](./images/s1-rhoso-lecture-fig-1.svg)
+
+Image source: [Introduction to Red Hat OpenStack Services on OpenShift](https://redhatquickcourses.github.io/rhoso-intro/rhoso-intro/1/ch1-intro/s1-rhoso-lecture.html)
+
+## OpenStack services architecture
+
+![OpenStack Services Architecture](./images/s1-fundamental-lecture-fig-1.svg)
+
+Image source: [Introduction to Red Hat OpenStack Services on OpenShift](https://redhatquickcourses.github.io/rhoso-intro/rhoso-intro/1/ch2-services/s1-fundamental-lecture.html)
+
+* Swift: Object Storage
+* Manila: Shared Filesystems
+* Octavia: Load balancer
+* Designate: DNS
+* Heat: Orchestration
+* Placement
+* Barbican: Key Management
+* Nova: Compute
+* Cinder: Block Storage
+* Neutron: Networking
+* Glance: Image
+* Horizon: Dashboard
+* Ironic: Bare Metal Provisioning
+* Ceilometer: Metering
+
+# General architecture of OpenStack services
+
+![General Architecture of OpenStack Services](./images/s6-services-lecture-fig-1.svg)
+
+Image source: [Red Hat OpenStack Services on OpenShift Architecture](https://redhatquickcourses.github.io/rhoso-arch/rhoso-arch/1/ch1-architecture/s6-services-lecture.html)
+
+# Multitenancy with OpenStack
+
+![Multitenancy with OpenStack](./images/s1-domains-projects-lecture-fig-1.svg)
+
+Image source: [Introduction to Red Hat OpenStack Services on OpenShift](https://redhatquickcourses.github.io/rhoso-intro/rhoso-intro/1/ch3-multitenancy/s1-domains-projects-lecture.html)

docs/guides/concept-guide/design.md

@@ -0,0 +1,24 @@
+---
+sidebar_label: Cluster design
+sidebar_position: 30
+---
+
+# Cluster design
+
+:::info
+
+Parts of this chapter are based on the [OpenStack Architecture Design Guide](https://docs.openstack.org/arch-design/index.html).
+The sources for this guide can be found in repostory [openstack/arch-design](https://github.com/openstack/arch-design)
+and have been published under the Apache Licence 2.0.
+
+:::
+
+## Compute architecture
+
+## Control plane architecture
+
+## Storage architecture
+
+## Network architecture
+
+## Identity architecture

docs/guides/concept-guide/hardware-bom.md

@@ -0,0 +1,132 @@
+---
+sidebar_label: Hardware Bill of Materials
+sidebar_position: 50
+---
+
+# Hardware Bill of Materials
+
+:::info
+
+The brands, models and configurations listed are examples. There is no
+single best specification for building a cluster. It always depends very
+much on the requirements of the cluster and the situation. The examples
+are not minimal and include various preferences of ours. The choice of
+hardware always depends very much on the requirements, the available budget
+and also the future plans of the cluster. There is no universal hardware
+recommendation that fits all cases. These are all just examples.
+
+:::
+
+## Control nodes
+
+A control node is responsible for running all or most of the OpenStack
+services that manage API services and their associated runtimes. These
+nodes are essential for users to interact with the cluster and maintain
+its managed state.
+
+However, control nodes typically do not run user virtual machines. It is
+therefore advisable to replicate the control nodes to ensure high availability
+and fault tolerance. A good starting point for achieving RAFT quorum is to have
+three control nodes.
+
+* 2x SSD with at least 480 GByte for the operating system
+* 4x NVMe with at least 960 GByte for the services
+* 128 GByte memory (it should be possible to upgrade to 256 GByte, or use 256
+  GByte directly)
+* Dual port NIC with 25G or 100G (depending on which leaf switches are used)
+* 2 CPU sockets each with at least 32 cores or 1 CPU socket with at least 64 cores
+
+Real world example:
+
+* https://www.supermicro.com/de/products/system/clouddc/1u/sys-121c-tn10r
+
+## Compute nodes
+
+Compute nodes are dedicated to running users' virtual machines. They do not
+host API services, storage services or network routers, other than the basic
+network infrastructure required to connect virtual machines.
+
+* 2x SSD or NVMe with at least 480 GByte for the operating system
+* 2x NVMe with at least 1.92 TByte for local storage recommended (if this is not implemented
+  at the start, the model should be selected so that NVMe devices can be added later,
+  the size depends on which CPU and how much memory is used, 7.68 TByte is more likely to be used)
+* Dual port NIC with 25G or 100G (depending on which leaf switches are used)
+* CPU sockets and memory depends on the requirement
+
+Real world example:
+
+* https://www.supermicro.com/de/products/twin
+
+## Storage nodes
+
+A dedicated storage node runs only storage services. This can be necessary in larger
+deployments to protect the storage services from ressource starvation through user
+workloads.
+
+Read the [Ceph hardware recommendations](https://docs.ceph.com/en/latest/start/hardware-recommendations/) first.
+
+* 2x SSD or NVMe with at least 480 GByte for the operating system
+* Dual port NIC with 100G (we recommend always using 100G for storage nodes)
+* Storage devices depends on the requirement
+* CPU sockets and memory depends on the storage devices used
+
+## Network nodes
+
+A dedicated network node runs only network services. This is normally necessary to be
+able to map safety zones. External networks terminate on the network nodes.
+
+Real world example:
+
+* [Supermicro SuperServer SYS-110D-8C-FRAN8TP](https://www.supermicro.com/en/products/system/iot/1u/sys-110d-8c-fran8tp)
+
+  * 2x SSD or NVMe with at least 480 GByte for the operating system
+  * 2x DIMM slots with 32 GByte modules, leave 2 DIMM slots open for later expansion
+  * If required, an additional dual port 25G or 100G NIC in the PCIe expansion slots
+  * Intel Xeon Processor D-2733NT (this is onboard and not selectable)
+
+## Manager nodes
+
+The manager node, also known as the deploy node or deployment node, is designated
+to manage the deployment process of all services. It is often also utilized to host
+components of the monitoring services. It serves as the operator's entry point into
+the cluster for operations.
+
+* 2x SSD or NVMe with at least 1.92 TByte for the operating system and the services
+* 64 GByte memory (it should be possible to upgrade to 128 GByte, or use 128 GByte directly)
+* Dual port NIC with 25G or 100G (depending on which leaf switches are used)
+* 1 CPU socket with at least 16 cores
+
+Real world example:
+
+* https://www.supermicro.com/de/products/system/clouddc/1u/sys-121c-tn10r
+
+## Switches
+
+### Management switches
+
+* 1G: [Edgecore AS4610-54T](https://www.edge-core.com/product/as4610-54t/)
+* 10G: [Edgecore DCS202 - AS5835-54T](https://www.edge-core.com/product/dcs202/)
+
+### Leaf switches
+
+It is recommended to always use 100G for the data plane and the storage nodes.
+Especially when using all-flash storage nodes, there is then enough bandwidth
+available. The more and the larger flash devices you use, the more bandwidth is
+required.
+
+With the leaf switches for the compute plane, it depends on how large the compute
+nodes are. The more CPU sockets/cores and the more memory the compute nodes have,
+the more bandwidth is required on the compute nodes. Depending on how large the racks
+are (or better how much power you can use in it), it may make sense to work with 100G
+switches for the compute plane or with 25G switches if 4x 25G per compute node are used
+instead of 2x 25G per compute node (if the compute nodes are large enough).
+
+* 25G: [Edgecore DCS203 - AS7326-56X](https://www.edge-core.com/product/dcs203/)
+* 100G: [Edgecore DCS204 - AS7726-32X](https://www.edge-core.com/product/dcs204/)
+
+### Spine switches
+
+* 100G: [Edgecore DCS204 - AS7726-32X](https://www.edge-core.com/product/dcs204/)
+* 400G: [Edgecore DCS510 - AS9716-32D](https://www.edge-core.com/product/dcs510/)
+
+## Network interface cards

docs/guides/concept-guide/index.md

@@ -9,6 +9,8 @@ sidebar_position: 10
 
 ![OSISM overview](./images/overview.drawio.png)
 
+## Components in a cluster
+
 * [Infrastructure as a Service (IaaS) with OpenStack](./components/openstack)
 * [Software Defined Storage (SDS) with Ceph](./components/ceph)
 * [Bare Metal as a Service (BMaaS) with Ironic](./components/ironic)
@@ -22,20 +24,35 @@ sidebar_position: 10
 * [Realtime insights with Netdata](./components/netdata)
 * [Simple virtualization & containerization with Proxmox VE](./components/proxmox)
 
-## Layered view
+## Requirements
 
-### Compute Plane
+## Layers in a cluster
 
-### Control Plane
+* [Compute Plane](./layers#compute-plane)
+* [Control Plane](./layers#control-plane)
+* [Data Plane](./layers#data-plane)
+* [Management Plane](./layers#management-plane)
+* [Monitoring Plane](./layers#monitoring-plane)
+* [Network Plane](./layers#network-plane)
 
-### Data Plane
+## Cluster design
 
-### Management Plane
+* [Compute architecture](./design#compute-architecture)
+* [Storage architecture](./design#storage-architecture)
+* [Network architecture](./design#network-architecture)
+* [Identity architecture](./design#identity-architecture)
+* [Control plane architecture](./design#control-plane-architecture)
 
-### Monitoring Plane
+## Use cases
 
-### Network Plane
+* [Hyper-converged infrastructure (HCI)](./use-cases#hyper-converged-infrastructure-hci)
 
-## Logical Process Architecture
+## Hardware Bill of Materials
 
-![OSISM architecture](./images/architecture.drawio.png)
+* [Control nodes](./hardware-bom#control-nodes)
+* [Compute nodes](./hardware-bom#compute-nodes)
+* [Storage nodes](./hardware-bom#storage-nodes)
+* [Network nodes](./hardware-bom#network-nodes)
+* [Manager nodes](./hardware-bom#manager-nodes)
+* [Switches](./hardware-bom#switches)
+* [Network interface cards](./hardware-bom#network-interface-cards)

docs/guides/concept-guide/layers.md

@@ -0,0 +1,13 @@
+---
+sidebar_label: Layers in a cluster
+sidebar_position: 20
+---
+
+# Layers in a cluster
+
+## Compute Plane
+## Control Plane
+## Data Plane
+## Management Plane
+## Monitoring Plane
+## Network Plane

docs/guides/concept-guide/nodes.md

@@ -0,0 +1,18 @@
+---
+sidebar_label: Nodes in a cluster
+sidebar_position: 25
+---
+
+# Nodes in a cluster
+
+## Compute Node
+
+## Control Node
+
+## Data Node
+
+## Management Node
+
+## Monitoring Node
+
+## Network Node

docs/guides/concept-guide/use-cases.md

@@ -0,0 +1,8 @@
+---
+sidebar_label: Use cases
+sidebar_position: 40
+---
+
+# Use cases
+
+## Hyper-converged infrastructure (HCI)