doc(victoria-k8s-stack): WiP .... first steps of documentation of the components we have, se DevFW/infra-deploy#13 (comment)

ref: https://likec4.dev/dsl/projects/#_top

.gitignore

@@ -0,0 +1 @@
+node_modules

devbox.json

@@ -0,0 +1,17 @@
+{
+  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.14.0/.schema/devbox.schema.json",
+  "packages": [
+    "nodejs@latest",
+    "terraform@latest"
+  ],
+  "shell": {
+    "init_hook": [
+      "echo 'Welcome to devbox!' > /dev/null"
+    ],
+    "scripts": {
+      "test": [
+        "echo \"Error: no test specified\" && exit 1"
+      ]
+    }
+  }
+}

devbox.lock

@@ -0,0 +1,121 @@
+{
+  "lockfile_version": "1",
+  "packages": {
+    "github:NixOS/nixpkgs/nixpkgs-unstable": {
+      "resolved": "github:NixOS/nixpkgs/2d9e4457f8e83120c9fdf6f1707ed0bc603e5ac9?lastModified=1741462378&narHash=sha256-ZF3YOjq%2BvTcH51S%2BqWa1oGA9FgmdJ67nTNPG2OIlXDc%3D"
+    },
+    "nodejs@latest": {
+      "last_modified": "2025-03-16T16:17:41Z",
+      "plugin_version": "0.0.2",
+      "resolved": "github:NixOS/nixpkgs/8f76cf16b17c51ae0cc8e55488069593f6dab645#nodejs_23",
+      "source": "devbox-search",
+      "version": "23.10.0",
+      "systems": {
+        "aarch64-darwin": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/dihlffh62qmgzsrxq1igwxicdyr3fn8a-nodejs-23.10.0",
+              "default": true
+            },
+            {
+              "name": "libv8",
+              "path": "/nix/store/ks94i4365833bykrzg3d3mqxnciygyrn-nodejs-23.10.0-libv8"
+            }
+          ],
+          "store_path": "/nix/store/dihlffh62qmgzsrxq1igwxicdyr3fn8a-nodejs-23.10.0"
+        },
+        "aarch64-linux": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/m7j1lf8a4z5bfla1m78pa3y12888hl7b-nodejs-23.10.0",
+              "default": true
+            },
+            {
+              "name": "libv8",
+              "path": "/nix/store/kfvlfxx83n2w2fyb8hiz4p4dc165r035-nodejs-23.10.0-libv8"
+            }
+          ],
+          "store_path": "/nix/store/m7j1lf8a4z5bfla1m78pa3y12888hl7b-nodejs-23.10.0"
+        },
+        "x86_64-darwin": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/nj0d1lc4nanqj7v4ibcgd26m3p5yfb0h-nodejs-23.10.0",
+              "default": true
+            },
+            {
+              "name": "libv8",
+              "path": "/nix/store/k5rvmvqyibamfxa7cfzjfd5ldmi38kf3-nodejs-23.10.0-libv8"
+            }
+          ],
+          "store_path": "/nix/store/nj0d1lc4nanqj7v4ibcgd26m3p5yfb0h-nodejs-23.10.0"
+        },
+        "x86_64-linux": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/m7imcmwi4hschl257dzc33gxciqlf4bm-nodejs-23.10.0",
+              "default": true
+            },
+            {
+              "name": "libv8",
+              "path": "/nix/store/wy7ysxmd2ygdc5zpbhf9ripwgvvvnwsd-nodejs-23.10.0-libv8"
+            }
+          ],
+          "store_path": "/nix/store/m7imcmwi4hschl257dzc33gxciqlf4bm-nodejs-23.10.0"
+        }
+      }
+    },
+    "terraform@latest": {
+      "last_modified": "2025-04-10T20:20:34Z",
+      "resolved": "github:NixOS/nixpkgs/d19cf9dfc633816a437204555afeb9e722386b76#terraform",
+      "source": "devbox-search",
+      "version": "1.11.4",
+      "systems": {
+        "aarch64-darwin": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/46l1vs4h00h1y3n3xxwzab0a16mawfcs-terraform-1.11.4",
+              "default": true
+            }
+          ],
+          "store_path": "/nix/store/46l1vs4h00h1y3n3xxwzab0a16mawfcs-terraform-1.11.4"
+        },
+        "aarch64-linux": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/knyqig364fi94f3z33q47jawv9b4h4sy-terraform-1.11.4",
+              "default": true
+            }
+          ],
+          "store_path": "/nix/store/knyqig364fi94f3z33q47jawv9b4h4sy-terraform-1.11.4"
+        },
+        "x86_64-darwin": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/9w7xlspipmx4kal4bagqnf76h0wv8lx8-terraform-1.11.4",
+              "default": true
+            }
+          ],
+          "store_path": "/nix/store/9w7xlspipmx4kal4bagqnf76h0wv8lx8-terraform-1.11.4"
+        },
+        "x86_64-linux": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/xlg2aqgy2fwilpfnla4313f39vs0hhmb-terraform-1.11.4",
+              "default": true
+            }
+          ],
+          "store_path": "/nix/store/xlg2aqgy2fwilpfnla4313f39vs0hhmb-terraform-1.11.4"
+        }
+      }
+    }
+  }
+}

docs/technical-documentation/.pages

@@ -0,0 +1,6 @@
+title: Technical doc
+arrange:
+  - concepts
+  - architecture
+  - product
+  - project

docs/technical-documentation/architecture/decisions/0002-openbao-as-identity-provider.md

@@ -0,0 +1,62 @@
+---
+status: "proposed"
+decision-makers: {list everyone involved in the decision}
+---
+
+<!-- markdownlint-disable-next-line MD025 -->
+# Replace Keycloak with OpenBao as OIDC Provider
+
+## Context and Problem Statement
+
+The EDP currently relies on Keycloak as the OpenID Connect (OIDC) provider to handle authentication and authorization. However, Keycloak is fairly complex and has quite some maintenance overhead, which will leads to increased operational effort. We need to determine if replacing Keycloak with OpenBao, a tool we already use for secrets management and which may support OIDC capabilities, can streamline our architecture and reduce these operational burdens.
+
+## Decision Drivers
+
+- Simplify architecture by reducing the number of tools in our ecosystem.
+- Reduce operational complexity and maintenance overhead to improve team efficiency.
+- Ensure seamless integration with existing systems, particularly leveraging our current use of OpenBao.
+- Maintain or enhance security and performance to meet platform requirements.
+
+## Considered Options
+
+- Keep using Keycloak
+- Replace Keycloak with OpenBao
+
+## Decision Outcome
+
+Chosen option: "Replace Keycloak with OpenBao", because it enables us to consolidate identity and secrets management into a single tool, reducing operational complexity, improving integration with our existing infrastructure, and potentially enhancing performance, provided OpenBao can meet our OIDC needs.
+
+### Consequences
+
+- *Good*, because it simplifies the architecture by reducing the number of tools we need to manage.
+- *Good*, because it may lower operational costs by eliminating a separate system and leveraging an existing open-source tool.
+- *Bad*, because additional configuration or development might be required to ensure OpenBao fully supports all necessary OIDC features.
+- *Bad*, because relying on a single tool for both identity and secrets management increases risk if OpenBao encounters issues.
+
+### Confirmation
+
+- Conduct a proof-of-concept to validate that OpenBao can effectively serve as an OIDC provider meeting our platform’s requirements.
+- Validate that all EDP components support the Authorization Code Flow
+- Review the design and implementation with the development team to confirm alignment with this decision.
+
+## Pros and Cons of the Options
+
+### Keep using Keycloak
+
+Keycloak is a mature, feature-rich OIDC provider widely used for authentication and authorization.
+- *Good*, because it offers extensive OIDC features, including support for single sign-on and various authentication protocols.
+- *Good*, because it is already integrated into our platform, minimizing immediate changes.
+- *Bad*, because its complexity increases configuration and maintenance efforts.
+- *Bad*, because maintaining it as a separate tool adds to operational overhead.
+
+### Replace Keycloak with OpenBao
+
+OpenBao, a fork of HashiCorp Vault, is currently used for secrets management and may be configurable as an OIDC provider.
+- *Good*, because consolidating identity and secrets management into one tool simplifies our architecture.
+- *Good*, because it leverages our existing OpenBao deployment, potentially improving integration and reducing costs.
+- *Bad*, because OpenBao may not natively support all advanced OIDC features provided by Keycloak, such as comprehensive user management.
+- *Bad*, because its community and documentation for OIDC use cases may be less robust compared to Keycloak.
+
+## More Information
+
+Before finalizing this decision, we must verify OpenBao’s OIDC capabilities against our specific authentication and authorization requirements, such as user federation and token issuance for our development platform. The team should also assess the long-term implications of relying heavily on OpenBao and consider revisiting this decision if significant gaps in OIDC functionality are identified during the proof-of-concept phase.

docs/technical-documentation/architecture/design/_index.md

@@ -0,0 +1,6 @@
+---
+title: Design
+weight: 1
+description: Edge Developver Framework Design
+---
+

docs/technical-documentation/architecture/design/mvp1-12-otc/index.md

@@ -0,0 +1,59 @@
+# MVP1-12-OTC Milestone
+
+History:
+* 24.04.25: Initial Arch done in lucid by Waldemar
+* 06.05.25: Ported to C4 by Stephan
+* 13.05.25: Review OTC-EDP
+
+
+https://lucid.app/lucidspark/7134abcb-0c5e-41e5-93da-7118e285a668/edit?invitationId=inv_fbf0d105-7023-4740-806e-fcbb522ea61a&page=0_0#
+
+## C4 Architecture
+
+* https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/edp-doc/src/branch/development/likec4/views/deployment/otc/otc.c4
+
+![alt text](./_assets/image.png)
+
+![alt text](./_assets/image-1.png)
+
+## Overall
+
+### Architecture
+
+![alt text](./_assets/EDPForgejoArch1.svg)
+
+### Work packages
+
+![alt text](./_assets/EDPForgejoArch2.svg)   
+
+## EDP Foundry
+
+### Sub-Components 'Internal Services' and 'Central Observaability'           
+
+![alt text](./_assets/EDPForgejoArch3.svg)
+
+## EDP (deployed per tenant)
+
+### Sub-Components 'Kubernetes' and 'Cloud Services'    
+
+![alt text](./_assets/EDPForgejoArch4.svg)
+
+## Operator (Provisioning Pipeline)
+
+### Sub-Components 'Forgejo-Actions' and 'ArgoCD'  
+
+![alt text](./_assets/EDPForgejoArch5.svg)
+
+![alt text](./_assets/EDPForgejoArch6.svg)
+
+# OTC EDP product review on 13.05.25
+
+![alt text](./_assets/edp-otc-1.png)
+
+![alt text](./_assets/edp-otc-2.png)
+
+![alt text](./_assets/edp-otc-3.png)
+
+![alt text](./_assets/edp-otc-4.png)
+
+![alt text](./_assets/edp-otc-5.png)

docs/technical-documentation/concepts/.pages

@@ -0,0 +1,6 @@
+title: Concepts
+arrange:
+  - overview.md
+  - general
+  - customer-developer
+  - edp-developer

docs/technical-documentation/concepts/edp-developer/.pages

@@ -0,0 +1,10 @@
+title: edgeDeveloper Framework
+arrange:
+  - storyline.md
+  - introduction.md
+  - edge-developer-framework.md
+  - platforming.md
+  - orchestrators.md
+  - cnoe.md
+  - cnoe-showtime.md
+  - conclusio.md

docs/technical-documentation/concepts/edp-developer/7_conclusio/likec4.config.json

@@ -0,0 +1,3 @@
+{
+  "name": "project-management"
+}

docs/technical-documentation/concepts/edp-developer/orchestrators.md

@@ -7,6 +7,7 @@ description: Next level platforming is orchestrating platforms
 ## Summary
 
 When defining and setting up platforms next two intrinsic problems arise:
+
 1. it is not declarative and automated
 2. it is not or least not easily changable
 
@@ -21,7 +22,7 @@ This is something extremely new since late 2023 - the rise of the automation of
 
 It was Humanitec creating a definition of platform architecture, as they needed to defien what they are building with their 'orchestrator':
 
-<img src="./vendor-neutral-idp-final.gif" width="600" alt="https://developer.humanitec.com/introduction/overview/">
+![https://developer.humanitec.com/introduction/overview/](./4_orchestrators/vendor-neutral-idp-final.gif)
 
 ## Declarative Platform Orchestration
 
@@ -29,16 +30,13 @@ Based on the refence architecture you next can build - or let's say 'orchestrate
 
 https://humanitec.com/reference-architectures
 
-<img src="./platform-architectures.webp" width="600" alt="https://humanitec.com/blog/aws-azure-and-gcp-open-source-reference-architectures-to-start-your-mvp">
+
+![https://humanitec.com/blog/aws-azure-and-gcp-open-source-reference-architectures-to-start-your-mvp](./4_orchestrators/platform-architectures.webp)
 
 > Hint: There is a [slides tool provided by McKinsey](https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures) to set up your own platform deign based on the reference architecture 
 
-
-{{% pageinfo color="info" %}}
-### What comes next?
-
-[Next](../cnoe/) we'll see how we are going to do platform orchestration with CNOE!
-{{% /pageinfo %}}
+> What comes next?
+> [Next](./cnoe.md) we'll see how we are going to do platform orchestration with CNOE!
 
 ## Addendum
 
@@ -46,6 +44,4 @@ https://humanitec.com/reference-architectures
 
 You remember the [capability mappings from the time before orchestration](../platforming)? Here we have a [similar setup based on Humanitecs platform engineering status ewhite paper](https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2):
 
-<img src="./platform-tooling-humanitec-platform-report-2024.PNG" width="600" alt="https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2 Whitepaper_ State of Platform Engineering Report.pdf">
-
-
+![https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2 Whitepaper_ State of Platform Engineering Report.pdf](./4_orchestrators/platform-tooling-humanitec-platform-report-2024.PNG)

docs/technical-documentation/concepts/edp-developer/platforming.md

@@ -18,7 +18,7 @@ Let's start with a look into the history of platform engineering. A good startin
 
 They create lots of [beautiful articles and insights](https://humanitec.com/blog), their own [platform products](https://humanitec.com/products/) and [basic concepts for the platform architecture](https://humanitec.com/platform-engineering) (we'll meet this later on!).
 
-<img src="./humanitec-history.png" width="600" alt="https://platformengineering.org/blog/the-story-of-platform-engineering">
+<img src="./3_platforming/humanitec-history.png" width="600" alt="https://platformengineering.org/blog/the-story-of-platform-engineering">
 
 
 ### Further nice reference to the raise of platforms
@@ -41,7 +41,7 @@ When looking at these 'capabilities', we have CNCF itself:
 
 There is a CNCF working group which provides the definition of [Capabilities of platforms](https://tag-app-delivery.cncf.io/whitepapers/platforms/#capabilities-of-platforms) and shows a first idea of the layered architecture of platforms as **service layer for developers** ("product and application teams"):
 
-<img src="./platforms-def.drawio.png" width="600">
+<img src="./3_platforming/platforms-def.drawio.png" width="600">
 
 
 > Important: As Platform engineer also notice the [platform-eng-maturity-model](https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/)
@@ -50,7 +50,7 @@ There is a CNCF working group which provides the definition of [Capabilities of
 
 Or, in another illustration for the platform as a developer service interface, which also defines the **'Platform Engineering Team'** inbetween: 
 
-<img src="./platform-self-services.webp" width="600" alt="https://medium.com/@bijit211987/what-is-platform-engineering-and-how-it-reduce-cognitive-load-on-developers-ac7805603925">
+<img src="./3_platforming/platform-self-services.webp" width="600" alt="https://medium.com/@bijit211987/what-is-platform-engineering-and-how-it-reduce-cognitive-load-on-developers-ac7805603925">
 
 ## How to set up Platforms
 
@@ -77,7 +77,7 @@ Build or buy - this is also in pltaform engineering a tweaked discussion, which
 {{% pageinfo color="info" %}}
 ### What comes next?
 
-[Next](../orchestrators/) we'll see how these concepts got structured!
+[Next](./orchestrators.md) we'll see how these concepts got structured!
 {{% /pageinfo %}}
 
 ## Addendum

docs/technical-documentation/concepts/edp-developer/storyline.md

@@ -1,3 +1,11 @@
+---
+title: 'Storyline'
+linktitle: Conceptual Onboarding
+weight: 20
+description: How to conceptually onboard onto the Edge Developer Framework (EDF) requirements and the designed solution
+---
+
+# Platform 101: Conceptual Onboarding
 
 ## Storyline 
 
@@ -24,5 +32,3 @@
 3. Don't miss to further investigate and truely understand **CNOE solution**
 
 ## Architecture
-
-