Merge pull request 'fix: added routes to domain name for prometheus, grafana, alertmanageradded argo cd to the reporting after successfull build' (#155) from fix/add_routes_to_domain into master

Reviewed-on: https://git.nationtech.io/NationTech/harmony/pulls/155

.cargo/config.toml

@@ -0,0 +1,5 @@
+[target.x86_64-pc-windows-msvc]
+rustflags = ["-C", "link-arg=/STACK:8000000"]
+
+[target.x86_64-pc-windows-gnu]
+rustflags = ["-C", "link-arg=-Wl,--stack,8000000"]

.dockerignore

@@ -0,0 +1,2 @@
+target/
+Dockerfile

.gitattributes

@@ -2,3 +2,5 @@ bootx64.efi filter=lfs diff=lfs merge=lfs -text
 grubx64.efi filter=lfs diff=lfs merge=lfs -text
 initrd filter=lfs diff=lfs merge=lfs -text
 linux filter=lfs diff=lfs merge=lfs -text
+data/okd/bin/* filter=lfs diff=lfs merge=lfs -text
+data/okd/installer_image/* filter=lfs diff=lfs merge=lfs -text

.gitea/workflows/check.yml

@@ -0,0 +1,18 @@
+name: Run Check Script
+on:
+  push:
+    branches:
+      - master
+  pull_request:
+
+jobs:
+  check:
+    runs-on: docker
+    container:
+      image: hub.nationtech.io/harmony/harmony_composer:latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Run check script
+        run: bash check.sh

.gitea/workflows/harmony_composer.yaml

@@ -0,0 +1,95 @@
+name: Compile and package harmony_composer
+on:
+  push:
+    branches:
+      - master
+
+jobs:
+  package_harmony_composer:
+    container:
+      image: hub.nationtech.io/harmony/harmony_composer:latest
+    runs-on: dind
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Build for Linux x86_64
+        run: cargo build --release --bin harmony_composer --target x86_64-unknown-linux-gnu
+
+      - name: Build for Windows x86_64 GNU
+        run: cargo build --release --bin harmony_composer --target x86_64-pc-windows-gnu
+
+      - name: Setup log into hub.nationtech.io
+        uses: docker/login-action@v3
+        with:
+          registry: hub.nationtech.io
+          username: ${{ secrets.HUB_BOT_USER }}
+          password: ${{ secrets.HUB_BOT_PASSWORD }}
+
+      # TODO: build ARM images and MacOS binaries (or other targets) too
+
+      - name: Update snapshot-latest tag
+        run: |
+          git config user.name "Gitea CI"
+          git config user.email "ci@nationtech.io"
+          git tag -f snapshot-latest
+          git push origin snapshot-latest --force
+
+      - name: Install jq
+        run: apt install -y jq # The current image includes apt lists so we don't have to apt update and rm /var/lib/apt... every time. But if the image is optimized it won't work anymore
+
+      - name: Create or update release
+        run: |
+          # First, check if release exists and delete it if it does
+          RELEASE_ID=$(curl -s -X GET \
+            -H "Authorization: token ${{ secrets.GITEATOKEN }}" \
+            "https://git.nationtech.io/api/v1/repos/nationtech/harmony/releases/tags/snapshot-latest" \
+            | jq -r '.id // empty')
+
+          if [ -n "$RELEASE_ID" ]; then
+            # Delete existing release
+            curl -X DELETE \
+              -H "Authorization: token ${{ secrets.GITEATOKEN }}" \
+              "https://git.nationtech.io/api/v1/repos/nationtech/harmony/releases/$RELEASE_ID"
+          fi
+
+          # Create new release
+          RESPONSE=$(curl -X POST \
+            -H "Authorization: token ${{ secrets.GITEATOKEN }}" \
+            -H "Content-Type: application/json" \
+            -d '{
+              "tag_name": "snapshot-latest",
+              "name": "Latest Snapshot",
+              "body": "Automated snapshot build from master branch",
+              "draft": false,
+              "prerelease": true
+            }' \
+            "https://git.nationtech.io/api/v1/repos/nationtech/harmony/releases")
+
+          echo "RELEASE_ID=$(echo $RESPONSE | jq -r '.id')" >> $GITHUB_ENV
+
+      - name: Upload Linux binary
+        run: |
+          curl -X POST \
+            -H "Authorization: token ${{ secrets.GITEATOKEN }}" \
+            -H "Content-Type: application/octet-stream" \
+            --data-binary "@target/x86_64-unknown-linux-gnu/release/harmony_composer" \
+            "https://git.nationtech.io/api/v1/repos/nationtech/harmony/releases/${{ env.RELEASE_ID }}/assets?name=harmony_composer"
+
+      - name: Upload Windows binary
+        run: |
+          curl -X POST \
+            -H "Authorization: token ${{ secrets.GITEATOKEN }}" \
+            -H "Content-Type: application/octet-stream" \
+            --data-binary "@target/x86_64-pc-windows-gnu/release/harmony_composer.exe" \
+            "https://git.nationtech.io/api/v1/repos/nationtech/harmony/releases/${{ env.RELEASE_ID }}/assets?name=harmony_composer.exe"
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
+      - name: Build and push
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: true
+          tags: hub.nationtech.io/harmony/harmony_composer:latest

.gitignore

@@ -1,3 +1,26 @@
-target
-private_repos
-log/
+### General ###
+private_repos/
+
+### Harmony ###
+harmony.log
+data/okd/installation_files*
+
+### Helm ###
+# Chart dependencies
+**/charts/*.tgz
+
+### Rust ###
+# Generated by Cargo
+# will have compiled files and executables
+debug/
+target/
+
+# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
+# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
+Cargo.lock
+
+# These are backup files generated by rustfmt
+**/*.rs.bk
+
+# MSVC Windows builds of rustc generate these, which store debugging information
+*.pdb

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "examples/try_rust_webapp/tryrust.org"]
+	path = examples/try_rust_webapp/tryrust.org
+	url = https://github.com/rust-dd/tryrust.org.git

.sqlx/query-2ea29df2326f7c84bd4100ad510a3fd4878dc2e217dc83f9bf45a402dfd62a91.json

@@ -0,0 +1,20 @@
+{
+  "db_name": "SQLite",
+  "query": "SELECT host_id FROM host_role_mapping WHERE role = ?",
+  "describe": {
+    "columns": [
+      {
+        "name": "host_id",
+        "ordinal": 0,
+        "type_info": "Text"
+      }
+    ],
+    "parameters": {
+      "Right": 1
+    },
+    "nullable": [
+      false
+    ]
+  },
+  "hash": "2ea29df2326f7c84bd4100ad510a3fd4878dc2e217dc83f9bf45a402dfd62a91"
+}

.sqlx/query-8d247918eca10a88b784ee353db090c94a222115c543231f2140cba27bd0f067.json

@@ -0,0 +1,32 @@
+{
+  "db_name": "SQLite",
+  "query": "\n        SELECT\n            p1.id,\n            p1.version_id,\n            p1.data as \"data: Json<PhysicalHost>\"\n        FROM\n            physical_hosts p1\n        INNER JOIN (\n            SELECT\n                id,\n                MAX(version_id) AS max_version\n            FROM\n                physical_hosts\n            GROUP BY\n                id\n        ) p2 ON p1.id = p2.id AND p1.version_id = p2.max_version\n        ",
+  "describe": {
+    "columns": [
+      {
+        "name": "id",
+        "ordinal": 0,
+        "type_info": "Text"
+      },
+      {
+        "name": "version_id",
+        "ordinal": 1,
+        "type_info": "Text"
+      },
+      {
+        "name": "data: Json<PhysicalHost>",
+        "ordinal": 2,
+        "type_info": "Blob"
+      }
+    ],
+    "parameters": {
+      "Right": 0
+    },
+    "nullable": [
+      false,
+      false,
+      false
+    ]
+  },
+  "hash": "8d247918eca10a88b784ee353db090c94a222115c543231f2140cba27bd0f067"
+}

.sqlx/query-934035c7ca6e064815393e4e049a7934b0a7fac04a4fe4b2a354f0443d630990.json

@@ -0,0 +1,32 @@
+{
+  "db_name": "SQLite",
+  "query": "SELECT id, version_id, data as \"data: Json<PhysicalHost>\" FROM physical_hosts WHERE id = ? ORDER BY version_id DESC LIMIT 1",
+  "describe": {
+    "columns": [
+      {
+        "name": "id",
+        "ordinal": 0,
+        "type_info": "Text"
+      },
+      {
+        "name": "version_id",
+        "ordinal": 1,
+        "type_info": "Text"
+      },
+      {
+        "name": "data: Json<PhysicalHost>",
+        "ordinal": 2,
+        "type_info": "Null"
+      }
+    ],
+    "parameters": {
+      "Right": 1
+    },
+    "nullable": [
+      false,
+      false,
+      false
+    ]
+  },
+  "hash": "934035c7ca6e064815393e4e049a7934b0a7fac04a4fe4b2a354f0443d630990"
+}

.sqlx/query-df7a7c9cfdd0972e2e0ce7ea444ba8bc9d708a4fb89d5593a0be2bbebde62aff.json

@@ -0,0 +1,12 @@
+{
+  "db_name": "SQLite",
+  "query": "\n        INSERT INTO host_role_mapping (host_id, role)\n        VALUES (?, ?)\n        ",
+  "describe": {
+    "columns": [],
+    "parameters": {
+      "Right": 2
+    },
+    "nullable": []
+  },
+  "hash": "df7a7c9cfdd0972e2e0ce7ea444ba8bc9d708a4fb89d5593a0be2bbebde62aff"
+}

.sqlx/query-f10f615ee42129ffa293e46f2f893d65a237d31d24b74a29c6a8d8420d255ab8.json

@@ -0,0 +1,12 @@
+{
+  "db_name": "SQLite",
+  "query": "INSERT INTO physical_hosts (id, version_id, data) VALUES (?, ?, ?)",
+  "describe": {
+    "columns": [],
+    "parameters": {
+      "Right": 3
+    },
+    "nullable": []
+  },
+  "hash": "f10f615ee42129ffa293e46f2f893d65a237d31d24b74a29c6a8d8420d255ab8"
+}

CONTRIBUTING.md

@@ -0,0 +1,36 @@
+# Contributing to the Harmony project
+
+## Write small P-R
+
+Aim for the smallest piece of work that is mergeable.
+
+Mergeable means that :
+
+- it does not break the build
+- it moves the codebase one step forward
+
+P-Rs can be many things, they do not have to be complete features.
+
+### What a P-R **should** be
+
+- Introduce a new trait : This will be the place to discuss the new trait addition, its design and implementation
+- A new implementation of a trait : a new concrete implementation of the LoadBalancer trait
+- A new CI check : something that improves quality, robustness, ci performance
+- Documentation improvements
+- Refactoring
+- Bugfix
+
+### What a P-R **should not** be
+
+- Large. Anything over 200 lines (excluding generated lines) should have a very good reason to be this large.
+- A mix of refactoring, bug fixes and new features.
+- Introducing multiple new features or ideas at once.
+- Multiple new implementations of a trait/functionnality at once
+
+The general idea is to keep P-Rs small and single purpose.
+
+## Commit message formatting
+
+We follow conventional commits guidelines.
+
+https://www.conventionalcommits.org/en/v1.0.0/

Cargo.toml

@@ -11,6 +11,10 @@ members = [
   "opnsense-config-xml",
   "harmony_cli",
   "k3d",
+  "harmony_composer",
+  "harmony_inventory_agent",
+  "harmony_secret_derive",
+  "harmony_secret", "adr/agent_discovery/mdns",
 ]
 
 [workspace.package]
@@ -19,27 +23,48 @@ readme = "README.md"
 license = "GNU AGPL v3"
 
 [workspace.dependencies]
-log = "0.4.22"
-env_logger = "0.11.5"
-derive-new = "0.7.0"
-async-trait = "0.1.82"
-tokio = { version = "1.40.0", features = ["io-std", "fs", "macros", "rt-multi-thread"] }
-cidr = "0.2.3"
-russh = "0.45.0"
-russh-keys = "0.45.0"
-rand = "0.8.5"
-url = "2.5.4"
-kube = "0.98.0"
-k8s-openapi = { version = "0.24.0", features = ["v1_30"] }
-serde_yaml = "0.9.34"
-serde-value = "0.7.0"
-http = "1.2.0"
-inquire = "0.7.5"
-
-[workspace.dependencies.uuid]
-version = "1.11.0"
-features = [
-  "v4",                # Lets you generate random UUIDs
-  "fast-rng",          # Use a faster (but still sufficiently random) RNG
-  "macro-diagnostics", # Enable better diagnostics for compile-time UUIDs
-]
+log = { version = "0.4", features = ["kv"] }
+env_logger = "0.11"
+derive-new = "0.7"
+async-trait = "0.1"
+tokio = { version = "1.40", features = [
+  "io-std",
+  "fs",
+  "macros",
+  "rt-multi-thread",
+] }
+cidr = { features = ["serde"], version = "0.2" }
+russh = "0.45"
+russh-keys = "0.45"
+rand = "0.9"
+url = "2.5"
+kube = { version = "1.1.0", features = [
+  "config",
+  "client",
+  "runtime",
+  "rustls-tls",
+  "ws",
+  "jsonpatch",
+] }
+k8s-openapi = { version = "0.25", features = ["v1_30"] }
+serde_yaml = "0.9"
+serde-value = "0.7"
+http = "1.2"
+inquire = "0.7"
+convert_case = "0.8"
+chrono = "0.4"
+similar = "2"
+uuid = { version = "1.11", features = ["v4", "fast-rng", "macro-diagnostics"] }
+pretty_assertions = "1.4.1"
+tempfile = "3.20.0"
+bollard = "0.19.1"
+base64 = "0.22.1"
+tar = "0.4.44"
+lazy_static = "1.5.0"
+directories = "6.0.0"
+thiserror = "2.0.14"
+serde = { version = "1.0.209", features = ["derive", "rc"] }
+serde_json = "1.0.127"
+askama = "0.14"
+sqlx = { version = "0.8", features = ["runtime-tokio", "sqlite" ] }
+reqwest = { version = "0.12", features = ["blocking", "stream", "rustls-tls", "http2", "json"], default-features = false }

Dockerfile

@@ -0,0 +1,26 @@
+FROM docker.io/rust:1.89.0 AS build
+
+WORKDIR /app
+
+COPY . .
+
+RUN cargo build --release --bin harmony_composer
+
+FROM docker.io/rust:1.89.0
+
+WORKDIR /app
+
+RUN rustup target add x86_64-pc-windows-gnu
+RUN rustup target add x86_64-unknown-linux-gnu
+RUN rustup component add rustfmt
+RUN rustup component add clippy
+
+RUN apt update
+
+# TODO: Consider adding more supported targets
+# nodejs for checkout action, docker for building containers, mingw for cross-compiling for windows
+RUN apt install -y nodejs docker.io mingw-w64
+
+COPY --from=build /app/target/release/harmony_composer .
+
+ENTRYPOINT ["/app/harmony_composer"]

README.md

@@ -1,33 +1,161 @@
-# Harmony : Open Infrastructure Orchestration
+# Harmony : Open-source infrastructure orchestration that treats your platform like first-class code
 
-## Quick demo
+_By [NationTech](https://nationtech.io)_
 
-`cargo run -p example-tui`
+[![Build](https://git.nationtech.io/NationTech/harmony/actions/workflows/check.yml/badge.svg)](https://git.nationtech.io/nationtech/harmony)
+[![License](https://img.shields.io/badge/license-AGPLv3-blue?style=flat-square)](LICENSE)
 
-This will launch Harmony's minimalist terminal ui which embeds a few demo scores.
+### Unify
 
-Usage instructions will be displayed at the bottom of the TUI.
+- **Project Scaffolding**
+- **Infrastructure Provisioning**
+- **Application Deployment**
+- **Day-2 operations**
 
-`cargo run --bin example-cli -- --help`
+All in **one strongly-typed Rust codebase**.
 
-This is the harmony CLI, a minimal implementation
+### Deploy anywhere
 
-The current help text:
+From a **developer laptop** to a **global production cluster**, a single **source of truth** drives the **full software lifecycle.**
 
-````
-Usage: example-cli [OPTIONS]
+---
 
-Options:
-  -y, --yes              Run score(s) or not
-  -f, --filter <FILTER>  Filter query
-  -i, --interactive      Run interactive TUI or not
-  -a, --all              Run all or nth, defaults to all
-  -n, --number <NUMBER>  Run nth matching, zero indexed [default: 0]
-  -l, --list             list scores, will also be affected by run filter
-  -h, --help             Print help
-  -V, --version          Print version```
+## 1 · The Harmony Philosophy
 
-## Core architecture
+Infrastructure is essential, but it shouldn’t be your core business. Harmony is built on three guiding principles that make modern platforms reliable, repeatable, and easy to reason about.
 
-![Harmony Core Architecture](docs/diagrams/Harmony_Core_Architecture.drawio.svg)
-````
+| Principle                              | What it means for you                                                                                                                                                                |
+| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Infrastructure as Resilient Code**   | Replace sprawling YAML and bash scripts with type-safe Rust. Test, refactor, and version your platform just like application code.                                                   |
+| **Prove It Works — Before You Deploy** | Harmony uses the compiler to verify that your application’s needs match the target environment’s capabilities at **compile-time**, eliminating an entire class of runtime outages.   |
+| **One Unified Model**                  | Software and infrastructure are a single system. Harmony models them together, enabling deep automation—from bare-metal servers to Kubernetes workloads—with zero context switching. |
+
+These principles surface as simple, ergonomic Rust APIs that let teams focus on their product while trusting the platform underneath.
+
+---
+
+## 2 · Quick Start
+
+The snippet below spins up a complete **production-grade Rust + Leptos Webapp** with monitoring. Swap it for your own scores to deploy anything from microservices to machine-learning pipelines.
+
+```rust
+use harmony::{
+    inventory::Inventory,
+    modules::{
+        application::{
+            ApplicationScore, RustWebFramework, RustWebapp,
+            features::{PackagingDeployment, rhob_monitoring::Monitoring},
+        },
+        monitoring::alert_channel::discord_alert_channel::DiscordWebhook,
+    },
+    topology::K8sAnywhereTopology,
+};
+use harmony_macros::hurl;
+use std::{path::PathBuf, sync::Arc};
+
+#[tokio::main]
+async fn main() {
+    let application = Arc::new(RustWebapp {
+        name: "harmony-example-leptos".to_string(),
+        project_root: PathBuf::from(".."), // <== Your project root, usually .. if you use the standard `/harmony` folder
+        framework: Some(RustWebFramework::Leptos),
+        service_port: 8080,
+    });
+
+    // Define your Application deployment and the features you want
+    let app = ApplicationScore {
+        features: vec![
+            Box::new(PackagingDeployment {
+                application: application.clone(),
+            }),
+            Box::new(Monitoring {
+                application: application.clone(),
+                alert_receiver: vec![
+                    Box::new(DiscordWebhook {
+                        name: "test-discord".to_string(),
+                        url: hurl!("https://discord.doesnt.exist.com"), // <== Get your discord webhook url
+                    }),
+                ],
+            }),
+        ],
+        application,
+    };
+
+    harmony_cli::run(
+        Inventory::autoload(),
+        K8sAnywhereTopology::from_env(), // <== Deploy to local automatically provisioned local k3d by default or connect to any kubernetes cluster
+        vec![Box::new(app)],
+        None,
+    )
+    .await
+    .unwrap();
+}
+```
+
+Run it:
+
+```bash
+cargo run
+```
+
+Harmony analyses the code, shows an execution plan in a TUI, and applies it once you confirm. Same code, same binary—every environment.
+
+---
+
+## 3 · Core Concepts
+
+| Term             | One-liner                                                                                            |
+| ---------------- | ---------------------------------------------------------------------------------------------------- |
+| **Score<T>**     | Declarative description of the desired state (e.g., `LAMPScore`).                                    |
+| **Interpret<T>** | Imperative logic that realises a `Score` on a specific environment.                                  |
+| **Topology**     | An environment (local k3d, AWS, bare-metal) exposing verified _Capabilities_ (Kubernetes, DNS, …).   |
+| **Maestro**      | Orchestrator that compiles Scores + Topology, ensuring all capabilities line up **at compile-time**. |
+| **Inventory**    | Optional catalogue of physical assets for bare-metal and edge deployments.                           |
+
+A visual overview is in the diagram below.
+
+[Harmony Core Architecture](docs/diagrams/Harmony_Core_Architecture.drawio.svg)
+
+---
+
+## 4 · Install
+
+Prerequisites:
+
+- Rust
+- Docker (if you deploy locally)
+- `kubectl` / `helm` for Kubernetes-based topologies
+
+```bash
+git clone https://git.nationtech.io/nationtech/harmony
+cd harmony
+cargo build --release          # builds the CLI, TUI and libraries
+```
+
+---
+
+## 5 · Learning More
+
+- **Architectural Decision Records** – dive into the rationale
+  - [ADR-001 · Why Rust](adr/001-rust.md)
+  - [ADR-003 · Infrastructure Abstractions](adr/003-infrastructure-abstractions.md)
+  - [ADR-006 · Secret Management](adr/006-secret-management.md)
+  - [ADR-011 · Multi-Tenant Cluster](adr/011-multi-tenant-cluster.md)
+
+- **Extending Harmony** – write new Scores / Interprets, add hardware like OPNsense firewalls, or embed Harmony in your own tooling (`/docs`).
+
+- **Community** – discussions and roadmap live in [GitLab issues](https://git.nationtech.io/nationtech/harmony/-/issues). PRs, ideas, and feedback are welcome!
+
+---
+
+## 6 · License
+
+Harmony is released under the **GNU AGPL v3**.
+
+> We choose a strong copyleft license to ensure the project—and every improvement to it—remains open and benefits the entire community. Fork it, enhance it, even out-innovate us; just keep it open.
+
+See [LICENSE](LICENSE) for the full text.
+
+---
+
+_Made with ❤️ & 🦀 by the NationTech and the Harmony community_

adr/000-ADR-Template.md

@@ -1,6 +1,6 @@
 # Architecture Decision Record: \<Title\>
 
-Name: \<Name\>
+Initial Author: \<Name\>
 
 Initial Date: \<Date\>
 

adr/009-helm-and-kustomize-handling.md

@@ -1,6 +1,6 @@
 # Architecture Decision Record: Helm and Kustomize Handling
 
-Name: Taha Hawa
+Initial Author: Taha Hawa
 
 Initial Date: 2025-04-15
 

adr/010-monitoring-alerting/architecture.rs

@@ -0,0 +1,73 @@
+pub trait MonitoringSystem {}
+
+// 1. Modified AlertReceiver trait:
+//    - Removed the problematic `clone` method.
+//    - Added `box_clone` which returns a Box<dyn AlertReceiver>.
+pub trait AlertReceiver {
+    type M: MonitoringSystem;
+    fn install(&self, sender: &Self::M) -> Result<(), String>;
+    // This method allows concrete types to clone themselves into a Box<dyn AlertReceiver>
+    fn box_clone(&self) -> Box<dyn AlertReceiver<M = Self::M>>;
+}
+#[derive(Clone)]
+struct Prometheus{}
+impl MonitoringSystem for Prometheus {}
+
+#[derive(Clone)] // Keep derive(Clone) for DiscordWebhook itself
+struct DiscordWebhook{}
+
+impl AlertReceiver for DiscordWebhook {
+    type M = Prometheus;
+    fn install(&self, sender: &Self::M) -> Result<(), String> {
+        // Placeholder for actual installation logic
+        println!("DiscordWebhook installed for Prometheus monitoring.");
+        Ok(())
+    }
+    // 2. Implement `box_clone` for DiscordWebhook:
+    //    This uses the derived `Clone` for DiscordWebhook to create a new boxed instance.
+    fn box_clone(&self) -> Box<dyn AlertReceiver<M = Self::M>> {
+        Box::new(self.clone())
+    }
+}
+
+// 3. Implement `std::clone::Clone` for `Box<dyn AlertReceiver<M= M>>`:
+//    This allows `Box<dyn AlertReceiver>` to be cloned.
+//    The `+ 'static` lifetime bound is often necessary for trait objects stored in collections,
+//    ensuring they live long enough.
+impl<M: MonitoringSystem + 'static> Clone for Box<dyn AlertReceiver<M= M>> {
+    fn clone(&self) -> Self {
+        self.box_clone() // Call the custom `box_clone` method
+    }
+}
+
+// MonitoringConfig can now derive Clone because its `receivers` field
+// (Vec<Box<dyn AlertReceiver<M = M>>>) is now cloneable.
+#[derive(Clone)]
+struct MonitoringConfig <M: MonitoringSystem + 'static>{
+    receivers: Vec<Box<dyn AlertReceiver<M = M>>>
+}
+
+// Example usage to demonstrate compilation and functionality
+fn main() {
+    let prometheus_instance = Prometheus{};
+    let discord_webhook_instance = DiscordWebhook{};
+
+    let mut config = MonitoringConfig {
+        receivers: Vec::new()
+    };
+
+    // Create a boxed alert receiver
+    let boxed_receiver: Box<dyn AlertReceiver<M = Prometheus>> = Box::new(discord_webhook_instance);
+    config.receivers.push(boxed_receiver);
+
+    // Clone the config, which will now correctly clone the boxed receiver
+    let cloned_config = config.clone();
+
+    println!("Original config has {} receivers.", config.receivers.len());
+    println!("Cloned config has {} receivers.", cloned_config.receivers.len());
+
+    // Example of using the installed receiver
+    if let Some(receiver) = config.receivers.get(0) {
+        let _ = receiver.install(&prometheus_instance);
+    }
+}

adr/010-monitoring-and-alerting.md

@@ -1,7 +1,7 @@
 # Architecture Decision Record: Monitoring and Alerting
 
-Proposed by: Willem Rolleman
-Date: April 28 2025
+Initial Author : Willem Rolleman
+Date : April 28 2025
 
 ## Status
 

adr/011-multi-tenant-cluster.md

@@ -0,0 +1,161 @@
+# Architecture Decision Record: Multi-Tenancy Strategy for Harmony Managed Clusters
+
+Initial Author: Jean-Gabriel Gill-Couture
+
+Initial Date: 2025-05-26
+
+## Status
+
+Proposed
+
+## Context
+
+Harmony manages production OKD/Kubernetes clusters that serve multiple clients with varying trust levels and operational requirements. We need a multi-tenancy strategy that provides:
+
+1. **Strong isolation** between client workloads while maintaining operational simplicity
+2. **Controlled API access** allowing clients self-service capabilities within defined boundaries
+3. **Security-first approach** protecting both the cluster infrastructure and tenant data
+4. **Harmony-native implementation** using our Score/Interpret pattern for automated tenant provisioning
+5. **Scalable management** supporting both small trusted clients and larger enterprise customers
+
+The official Kubernetes multi-tenancy documentation identifies two primary models: namespace-based isolation and virtual control planes per tenant. Given Harmony's focus on operational simplicity, provider-agnostic abstractions (ADR-003), and hexagonal architecture (ADR-002), we must choose an approach that balances security, usability, and maintainability.
+
+Our clients represent a hybrid tenancy model:
+- **Customer multi-tenancy**: Each client operates independently with no cross-tenant trust
+- **Team multi-tenancy**: Individual clients may have multiple team members requiring coordinated access
+- **API access requirement**: Unlike pure SaaS scenarios, clients need controlled Kubernetes API access for self-service operations
+
+The official kubernetes documentation on multi tenancy heavily inspired this ADR : https://kubernetes.io/docs/concepts/security/multi-tenancy/
+
+## Decision
+
+Implement **namespace-based multi-tenancy** with the following architecture:
+
+### 1. Network Security Model
+- **Private cluster access**: Kubernetes API and OpenShift console accessible only via WireGuard VPN
+- **No public exposure**: Control plane endpoints remain internal to prevent unauthorized access attempts
+- **VPN-based authentication**: Initial access control through WireGuard client certificates
+
+### 2. Tenant Isolation Strategy
+- **Dedicated namespace per tenant**: Each client receives an isolated namespace with access limited only to the required resources and operations
+- **Complete network isolation**: NetworkPolicies prevent cross-namespace communication while allowing full egress to public internet
+- **Resource governance**: ResourceQuotas and LimitRanges enforce CPU, memory, and storage consumption limits
+- **Storage access control**: Clients can create PersistentVolumeClaims but cannot directly manipulate PersistentVolumes or access other tenants' storage
+
+### 3. Access Control Framework
+- **Principle of Least Privilege**: RBAC grants only necessary permissions within tenant namespace scope
+- **Namespace-scoped**: Clients can create/modify/delete resources within their namespace
+- **Cluster-level restrictions**: No access to cluster-wide resources, other namespaces, or sensitive cluster operations
+- **Whitelisted operations**: Controlled self-service capabilities for ingress, secrets, configmaps, and workload management
+
+### 4. Identity Management Evolution
+- **Phase 1**: Manual provisioning of VPN access and Kubernetes ServiceAccounts/Users
+- **Phase 2**: Migration to Keycloak-based identity management (aligning with ADR-006) for centralized authentication and lifecycle management
+
+### 5. Harmony Integration
+- **TenantScore implementation**: Declarative tenant provisioning using Harmony's Score/Interpret pattern
+- **Topology abstraction**: Tenant configuration abstracted from underlying Kubernetes implementation details
+- **Automated deployment**: Complete tenant setup automated through Harmony's orchestration capabilities
+
+## Rationale
+
+### Network Security Through VPN Access
+- **Defense in depth**: VPN requirement adds critical security layer preventing unauthorized cluster access
+- **Simplified firewall rules**: No need for complex public endpoint protections or rate limiting
+- **Audit capability**: VPN access provides clear audit trail of cluster connections
+- **Aligns with enterprise practices**: Most enterprise customers already use VPN infrastructure
+
+### Namespace Isolation vs Virtual Control Planes
+Following Kubernetes official guidance, namespace isolation provides:
+- **Lower resource overhead**: Virtual control planes require dedicated etcd, API server, and controller manager per tenant
+- **Operational simplicity**: Single control plane to maintain, upgrade, and monitor
+- **Cross-tenant service integration**: Enables future controlled cross-tenant communication if required
+- **Proven stability**: Namespace-based isolation is well-tested and widely deployed
+- **Cost efficiency**: Significantly lower infrastructure costs compared to dedicated control planes
+
+### Hybrid Tenancy Model Suitability
+Our approach addresses both customer and team multi-tenancy requirements:
+- **Customer isolation**: Strong network and RBAC boundaries prevent cross-tenant interference
+- **Team collaboration**: Multiple team members can share namespace access through group-based RBAC
+- **Self-service balance**: Controlled API access enables client autonomy without compromising security
+
+### Harmony Architecture Alignment
+- **Provider agnostic**: TenantScore abstracts multi-tenancy concepts, enabling future support for other Kubernetes distributions
+- **Hexagonal architecture**: Tenant management becomes an infrastructure capability accessed through well-defined ports
+- **Declarative automation**: Tenant lifecycle fully managed through Harmony's Score execution model
+
+## Consequences
+
+### Positive Consequences
+- **Strong security posture**: VPN + namespace isolation provides robust tenant separation
+- **Operational efficiency**: Single cluster management with automated tenant provisioning
+- **Client autonomy**: Self-service capabilities reduce operational support burden
+- **Scalable architecture**: Can support hundreds of tenants per cluster without architectural changes
+- **Future flexibility**: Foundation supports evolution to more sophisticated multi-tenancy models
+- **Cost optimization**: Shared infrastructure maximizes resource utilization
+
+### Negative Consequences
+- **VPN operational overhead**: Requires VPN infrastructure management
+- **Manual provisioning complexity**: Phase 1 manual user management creates administrative burden
+- **Network policy dependency**: Requires CNI with NetworkPolicy support (OVN-Kubernetes provides this and is the OKD/Openshift default)
+- **Cluster-wide resource limitations**: Some advanced Kubernetes features require cluster-wide access
+- **Single point of failure**: Cluster outage affects all tenants simultaneously
+
+### Migration Challenges
+- **Legacy client integration**: Existing clients may need VPN client setup and credential migration
+- **Monitoring complexity**: Per-tenant observability requires careful metric and log segmentation
+- **Backup considerations**: Tenant data backup must respect isolation boundaries
+
+## Alternatives Considered
+
+### Alternative 1: Virtual Control Plane Per Tenant
+**Pros**: Complete control plane isolation, full Kubernetes API access per tenant
+**Cons**: 3-5x higher resource usage, complex cross-tenant networking, operational complexity scales linearly with tenants
+
+**Rejected**: Resource overhead incompatible with cost-effective multi-tenancy goals
+
+### Alternative 2: Dedicated Clusters Per Tenant
+**Pros**: Maximum isolation, independent upgrade cycles, simplified security model
+**Cons**: Exponential operational complexity, prohibitive costs, resource waste
+
+**Rejected**: Operational overhead makes this approach unsustainable for multiple clients
+
+### Alternative 3: Public API with Advanced Authentication
+**Pros**: No VPN requirement, potentially simpler client access
+**Cons**: Larger attack surface, complex rate limiting and DDoS protection, increased security monitoring requirements
+
+**Rejected**: Risk/benefit analysis favors VPN-based access control
+
+### Alternative 4: Service Mesh Based Isolation
+**Pros**: Fine-grained traffic control, encryption, advanced observability
+**Cons**: Significant operational complexity, performance overhead, steep learning curve
+
+**Rejected**: Complexity overhead outweighs benefits for current requirements; remains option for future enhancement
+
+## Additional Notes
+
+### Implementation Roadmap
+1. **Phase 1**: Implement VPN access and manual tenant provisioning
+2. **Phase 2**: Deploy TenantScore automation for namespace, RBAC, and NetworkPolicy management
+4. **Phase 3**: Work on privilege escalation from pods, audit for weaknesses, enforce security policies on pod runtimes
+3. **Phase 4**: Integrate Keycloak for centralized identity management
+4. **Phase 5**: Add advanced monitoring and per-tenant observability
+
+### TenantScore Structure Preview
+```rust
+pub struct TenantScore {
+    pub tenant_config: TenantConfig,
+    pub resource_quotas: ResourceQuotaConfig,
+    pub network_isolation: NetworkIsolationPolicy,
+    pub storage_access: StorageAccessConfig,
+    pub rbac_config: RBACConfig,
+}
+```
+
+### Future Enhancements
+- **Cross-tenant service mesh**: For approved inter-tenant communication
+- **Advanced monitoring**: Per-tenant Prometheus/Grafana instances
+- **Backup automation**: Tenant-scoped backup policies
+- **Cost allocation**: Detailed per-tenant resource usage tracking
+
+This ADR establishes the foundation for secure, scalable multi-tenancy in Harmony-managed clusters while maintaining operational simplicity and cost effectiveness. A follow-up ADR will detail the Tenant abstraction and user management mechanisms within the Harmony framework.

adr/011-tenant/NetworkPolicy.yaml

@@ -0,0 +1,41 @@
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: tenant-isolation-policy
+  namespace: testtenant
+spec:
+  podSelector: {}  # Selects all pods in the namespace
+  policyTypes:
+  - Ingress
+  - Egress
+  ingress:
+  - from:
+    - podSelector: {}  # Allow from all pods in the same namespace
+  egress:
+  - to:
+    - podSelector: {}  # Allow to all pods in the same namespace
+  - to:
+    - podSelector: {}
+      namespaceSelector: 
+        matchLabels:
+          kubernetes.io/metadata.name: openshift-dns # Target the openshift-dns namespace
+    # Note, only opening port 53 is not enough, will have to dig deeper into this one eventually
+    # ports:
+    # - protocol: UDP
+    #   port: 53
+    # - protocol: TCP
+    #   port: 53
+  # Allow egress to public internet only
+  - to:
+    - ipBlock:
+        cidr: 0.0.0.0/0
+        except:
+        - 10.0.0.0/8      # RFC1918
+        - 172.16.0.0/12   # RFC1918
+        - 192.168.0.0/16  # RFC1918
+        - 169.254.0.0/16  # Link-local
+        - 127.0.0.0/8     # Loopback
+        - 224.0.0.0/4     # Multicast
+        - 240.0.0.0/4     # Reserved
+        - 100.64.0.0/10   # Carrier-grade NAT
+        - 0.0.0.0/8       # Reserved

adr/011-tenant/TestDeployment.yaml

@@ -0,0 +1,95 @@
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: testtenant
+---
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: testtenant2
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: test-web
+  namespace: testtenant
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: test-web
+  template:
+    metadata:
+      labels:
+        app: test-web
+    spec:
+      containers:
+      - name: nginx
+        image: nginxinc/nginx-unprivileged
+        ports:
+        - containerPort: 80
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: test-web
+  namespace: testtenant
+spec:
+  selector:
+    app: test-web
+  ports:
+  - port: 80
+    targetPort: 8080
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: test-client
+  namespace: testtenant
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: test-client
+  template:
+    metadata:
+      labels:
+        app: test-client
+    spec:
+      containers:
+      - name: curl
+        image: curlimages/curl:latest
+        command: ["/bin/sh", "-c", "sleep 3600"]
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: test-web
+  namespace: testtenant2
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: test-web
+  template:
+    metadata:
+      labels:
+        app: test-web
+    spec:
+      containers:
+      - name: nginx
+        image: nginxinc/nginx-unprivileged
+        ports:
+        - containerPort: 80
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: test-web
+  namespace: testtenant2
+spec:
+  selector:
+    app: test-web
+  ports:
+  - port: 80
+    targetPort: 8080

adr/012-project-delivery-automation.md

@@ -0,0 +1,63 @@
+# Architecture Decision Record: \<Title\>
+
+Initial Author: Jean-Gabriel Gill-Couture
+
+Initial Date: 2025-06-04
+
+Last Updated Date: 2025-06-04
+
+## Status
+
+Proposed
+
+## Context
+
+As Harmony's goal is to make software delivery easier, we must provide an easy way for developers to express their app's semantics and dependencies with great abstractions, in a similar fashion to what the score.dev project is doing.
+
+Thus, we started working on ways to package common types of applications such as LAMP, which we started working on with `LAMPScore`.
+
+Now is time for the next step : we want to pave the way towards complete lifecycle automation. To do this, we will start with a way to execute Harmony's modules easily from anywhere, starting with locally and in CI environments.
+
+## Decision
+
+To achieve easy, portable execution of Harmony, we will follow this architecture :
+
+- Host a basic harmony release that is compiled with the CLI by our gitea/github server
+    - This binary will do the following : check if there is a `harmony` folder in the current path
+    - If yes
+        - Check if cargo is available locally and compile the harmony binary, or compile the harmony binary using a rust docker container, if neither cargo or a container runtime is available, output a message explaining the situation
+        - Run the newly compiled binary. (Ideally using pid handoff like exec does but some research around this should be done. I think handing off the process is to help with OS interaction such as terminal apps, signals, exit codes, process handling, etc but there might be some side effects)
+    - If not
+        - Suggest initializing a project by auto detecting what the project looks like
+        - When the project type cannot be auto detected, provide links to Harmony's documentation on how to set up a project, a link to the examples folder, and a ask the user if he wants to initialize an empty Harmony project in the current folder
+            - harmony/Cargo.toml with dependencies set
+            - harmony/src/main.rs with an example LAMPScore setup and ready to run
+- This same binary can be used in a CI environment to run the target project's Harmony module. By default, we provide these opinionated steps :
+    1. **An empty check step.** The purpose of this step is to run all tests and checks against the codebase. For complex projects this could involve a very complex pipeline of test environments setup and execution but this is out of scope for now. This is not handled by harmony. For projects with automatic setup, we can fill this step with something like `cargo fmt --check; cargo test; cargo build` but Harmony is not directly involved in the execution of this step.
+    2. **Package and publish.** Once all checks have passed, the production ready container is built and pushed to a registry. This is done by Harmony.
+    3. **Deploy to staging automatically.** 
+    4. **Run a sanity check on staging.** As Harmony is responsible for deploying, Harmony should have all the knowledge of how to perform a sanity check on the staging environment. This will, most of the time, be a simple verification of the kubernetes health of all deployed components, and a poke on the public endpoint when there is one.
+    5. **Deploy to production automatically.** Many projects will require manual approval here, this can be easily set up in the CI afterwards, but our opinion is that 
+    6. **Run a sanity check on production.** Same check as staging, but on production.
+
+*Note on providing a base pipeline :* Having a complete pipeline set up automatically will encourage development teams to build upon these by adding tests where they belong. The goal here is to provide an opiniated solution that works for most small and large projects. Of course, many orgnizations will need to add steps such as deploying to sandbox environments, requiring more advanced approvals, more complex publication and coordination with other projects. But this here encompasses the basics required to build and deploy software reliably at any scale.
+
+### Environment setup
+
+TBD : For now, environments (tenants) will be set up and configured manually. Harmony will rely on the kubeconfig provided in the environment where it is running to deploy in the namespace.
+
+For the CD tool such as Argo or Flux they will be activated by default by Harmony when using application level Scores such as LAMPScore in a similar way that the container is automatically built. Then, CI deployment steps will be notifying the CD tool using its API of the new release to deploy.
+
+## Rationale
+
+Reasoning behind the decision
+
+## Consequences
+
+Pros/Cons of chosen solution
+
+## Alternatives considered
+
+Pros/Cons of various proposed solutions considered
+
+## Additional Notes

adr/013-monitoring-notifications.md

@@ -0,0 +1,78 @@
+# Architecture Decision Record: Monitoring Notifications
+
+Initial Author: Taha Hawa
+
+Initial Date: 2025-06-26
+
+Last Updated Date: 2025-06-26
+
+## Status
+
+Proposed
+
+## Context
+
+We need to send notifications (typically from AlertManager/Prometheus) and we need to receive said notifications on mobile devices for sure in some way, whether it's push messages, SMS, phone call, email, etc or all of the above.
+
+## Decision
+
+We should go with https://ntfy.sh except host it ourselves.
+
+`ntfy` is an open source solution written in Go that has the features we need.
+
+## Rationale
+
+`ntfy` has pretty much everything we need (push notifications, email forwarding, receives via webhook), and nothing/not much we don't. Good fit, lightweight.
+
+## Consequences
+
+Pros:
+
+- topics, with ACLs
+- lightweight
+- reliable
+- easy to configure
+- mobile app
+  - the mobile app can listen via websocket, poll, or receive via Firebase/GCM on Android, or similar on iOS.
+- Forward to email
+- Text-to-Speech phone call messages using Twilio integration
+- Operates based on simple HTTP requests/Webhooks, easily usable via AlertManager
+
+Cons:
+
+- No SMS pushes
+- SQLite DB, makes it harder to HA/scale
+
+## Alternatives considered
+
+[AWS SNS](https://aws.amazon.com/sns/):
+Pros:
+
+- highly reliable
+- no hosting needed
+
+Cons:
+
+- no control, not self hosted
+- costs (per usage)
+
+[Apprise](https://github.com/caronc/apprise):
+Pros:
+
+- Way more ways of sending notifications
+- Can use ntfy as one of the backends/ways of sending
+
+Cons:
+
+- Way too overkill for what we need in terms of features
+
+[Gotify](https://github.com/gotify/server):
+Pros:
+
+- simple, lightweight, golang, etc
+
+Cons:
+
+- Pushes topics are per-user
+
+## Additional Notes

adr/agent_discovery/mdns/Cargo.toml

@@ -0,0 +1,17 @@
+[package]
+name = "mdns"
+edition = "2024"
+version.workspace = true
+readme.workspace = true
+license.workspace = true
+
+[dependencies]
+mdns-sd = "0.14"
+tokio = { version = "1", features = ["full"] }
+futures = "0.3"
+dmidecode = "0.2" # For getting the motherboard ID on the agent
+log.workspace=true
+env_logger.workspace=true
+clap = { version = "4.5.46", features = ["derive"] }
+get_if_addrs = "0.5.3"
+local-ip-address = "0.6.5"

adr/agent_discovery/mdns/src/advertise.rs

@@ -0,0 +1,60 @@
+// harmony-agent/src/main.rs
+
+use log::info;
+use mdns_sd::{ServiceDaemon, ServiceInfo};
+use std::collections::HashMap;
+
+use crate::SERVICE_TYPE;
+
+// The service we are advertising.
+const SERVICE_PORT: u16 = 43210; // A port for the service. It needs one, even if unused.
+
+pub async fn advertise() {
+    info!("Starting Harmony Agent...");
+
+    // Get a unique ID for this machine.
+    let motherboard_id = "some motherboard id";
+    let instance_name = format!("harmony-agent-{}", motherboard_id);
+    info!("This agent's instance name: {}", instance_name);
+    info!("Advertising with ID: {}", motherboard_id);
+
+    // Create a new mDNS daemon.
+    let mdns = ServiceDaemon::new().expect("Failed to create mDNS daemon");
+
+    // Create a TXT record HashMap to hold our metadata.
+    let mut properties = HashMap::new();
+    properties.insert("id".to_string(), motherboard_id.to_string());
+    properties.insert("version".to_string(), "1.0".to_string());
+
+    // Create the service information.
+    // The instance name should be unique on the network.
+    let local_ip = local_ip_address::local_ip().unwrap();
+    let service_info = ServiceInfo::new(
+        SERVICE_TYPE,
+        &instance_name,
+        "harmony-host.local.", // A hostname for the service
+        local_ip,
+        // "0.0.0.0",
+        SERVICE_PORT,
+        Some(properties),
+    )
+    .expect("Failed to create service info");
+
+    // Register our service with the daemon.
+    mdns.register(service_info)
+        .expect("Failed to register service");
+
+    info!(
+        "Service '{}' registered and now being advertised.",
+        instance_name
+    );
+    info!("Agent is running. Press Ctrl+C to exit.");
+
+    for iface in get_if_addrs::get_if_addrs().unwrap() {
+        println!("{:#?}", iface);
+    }
+
+    // Keep the agent running indefinitely.
+    tokio::signal::ctrl_c().await.unwrap();
+    info!("Shutting down agent.");
+}

adr/agent_discovery/mdns/src/discover.rs

@@ -0,0 +1,109 @@
+use mdns_sd::{ServiceDaemon, ServiceEvent};
+
+use crate::SERVICE_TYPE;
+
+pub async fn discover() {
+    println!("Starting Harmony Master and browsing for agents...");
+
+    // Create a new mDNS daemon.
+    let mdns = ServiceDaemon::new().expect("Failed to create mDNS daemon");
+
+    // Start browsing for the service type.
+    // The receiver will be a stream of events.
+    let receiver = mdns.browse(SERVICE_TYPE).expect("Failed to browse");
+
+    println!(
+        "Listening for mDNS events for '{}'. Press Ctrl+C to exit.",
+        SERVICE_TYPE
+    );
+
+    std::thread::spawn(move || {
+        while let Ok(event) = receiver.recv() {
+            match event {
+                ServiceEvent::ServiceData(resolved) => {
+                    println!("Resolved a new service: {}", resolved.fullname);
+                }
+                other_event => {
+                    println!("Received other event: {:?}", &other_event);
+                }
+            }
+        }
+    });
+
+    // Gracefully shutdown the daemon.
+    std::thread::sleep(std::time::Duration::from_secs(1000000));
+    mdns.shutdown().unwrap();
+
+    // Process events as they come in.
+    // while let Ok(event) = receiver.recv_async().await {
+    //     debug!("Received event {event:?}");
+    //     // match event {
+    //     //     ServiceEvent::ServiceFound(svc_type, fullname) => {
+    //     //         println!("\n--- Agent Discovered ---");
+    //     //         println!("  Service Name: {}", fullname());
+    //     //         // You can now resolve this service to get its IP, port, and TXT records
+    //     //         // The resolve operation is a separate network call.
+    //     //         let receiver = mdns.browse(info.get_fullname()).unwrap();
+    //     //         if let Ok(resolve_event) = receiver.recv_timeout(Duration::from_secs(2)) {
+    //     //              if let ServiceEvent::ServiceResolved(info) = resolve_event {
+    //     //                 let ip = info.get_addresses().iter().next().unwrap();
+    //     //                 let port = info.get_port();
+    //     //                 let motherboard_id = info.get_property("id").map_or("N/A", |v| v.val_str());
+    //     //
+    //     //                 println!("  IP: {}:{}", ip, port);
+    //     //                 println!("  Motherboard ID: {}", motherboard_id);
+    //     //                 println!("------------------------");
+    //     //
+    //     //                 // TODO: Add this agent to your central list of discovered hosts.
+    //     //              }
+    //     //         } else {
+    //     //             println!("Could not resolve service '{}' in time.", info.get_fullname());
+    //     //         }
+    //     //     }
+    //     //     ServiceEvent::ServiceRemoved(info) => {
+    //     //         println!("\n--- Agent Removed ---");
+    //     //         println!("  Service Name: {}", info.get_fullname());
+    //     //         println!("---------------------");
+    //     //         // TODO: Remove this agent from your list.
+    //     //     }
+    //     //     _ => {
+    //     //         // We don't care about other event types for this example
+    //     //     }
+    //     // }
+    // }
+}
+
+async fn _discover_example() {
+    use mdns_sd::{ServiceDaemon, ServiceEvent};
+
+    // Create a daemon
+    let mdns = ServiceDaemon::new().expect("Failed to create daemon");
+
+    // Use recently added `ServiceEvent::ServiceData`.
+    mdns.use_service_data(true)
+        .expect("Failed to use ServiceData");
+
+    // Browse for a service type.
+    let service_type = "_mdns-sd-my-test._udp.local.";
+    let receiver = mdns.browse(service_type).expect("Failed to browse");
+
+    // Receive the browse events in sync or async. Here is
+    // an example of using a thread. Users can call `receiver.recv_async().await`
+    // if running in async environment.
+    std::thread::spawn(move || {
+        while let Ok(event) = receiver.recv() {
+            match event {
+                ServiceEvent::ServiceData(resolved) => {
+                    println!("Resolved a new service: {}", resolved.fullname);
+                }
+                other_event => {
+                    println!("Received other event: {:?}", &other_event);
+                }
+            }
+        }
+    });
+
+    // Gracefully shutdown the daemon.
+    std::thread::sleep(std::time::Duration::from_secs(1));
+    mdns.shutdown().unwrap();
+}

adr/agent_discovery/mdns/src/main.rs

@@ -0,0 +1,31 @@
+use clap::{Parser, ValueEnum};
+
+mod advertise;
+mod discover;
+
+#[derive(Parser, Debug)]
+#[command(version, about, long_about = None)]
+struct Args {
+    #[arg(value_enum)]
+    profile: Profiles,
+}
+
+#[derive(Copy, Clone, Debug, PartialEq, Eq, PartialOrd, Ord, ValueEnum)]
+enum Profiles {
+    Advertise,
+    Discover,
+}
+
+// The service type we are looking for.
+const SERVICE_TYPE: &str = "_harmony._tcp.local.";
+
+#[tokio::main]
+async fn main() {
+    env_logger::init();
+    let args = Args::parse();
+
+    match args.profile {
+        Profiles::Advertise => advertise::advertise().await,
+        Profiles::Discover => discover::discover().await,
+    }
+}

check.sh

@@ -1,5 +1,8 @@
 #!/bin/sh
 set -e
+
+rustc --version
 cargo check --all-targets --all-features --keep-going
 cargo fmt --check
+cargo clippy
 cargo test

data/okd/installer_image/scos-live-initramfs.x86_64.img

@@ -0,0 +1 @@
+scos-9.0.20250510-0-live-initramfs.x86_64.img

data/okd/installer_image/scos-live-kernel.x86_64

@@ -0,0 +1 @@
+scos-9.0.20250510-0-live-kernel.x86_64

data/okd/installer_image/scos-live-rootfs.x86_64.img

@@ -0,0 +1 @@
+scos-9.0.20250510-0-live-rootfs.x86_64.img

data/pxe/okd/README.md

@@ -0,0 +1,8 @@
+Here lies all the data files required for an OKD cluster PXE boot setup.
+
+This inclues ISO files, binary boot files, ipxe, etc.
+
+TODO as of august 2025 :
+
+- `harmony_inventory_agent` should be downloaded from official releases, this embedded version is practical for now though
+- The cluster ssh key should be generated and handled by harmony with the private key saved in a secret store

data/pxe/okd/http_files/.gitattributes

@@ -0,0 +1,9 @@
+harmony_inventory_agent filter=lfs diff=lfs merge=lfs -text
+os filter=lfs diff=lfs merge=lfs -text
+os/centos-stream-9 filter=lfs diff=lfs merge=lfs -text
+os/centos-stream-9/images filter=lfs diff=lfs merge=lfs -text
+os/centos-stream-9/initrd.img filter=lfs diff=lfs merge=lfs -text
+os/centos-stream-9/vmlinuz filter=lfs diff=lfs merge=lfs -text
+os/centos-stream-9/images/efiboot.img filter=lfs diff=lfs merge=lfs -text
+os/centos-stream-9/images/install.img filter=lfs diff=lfs merge=lfs -text
+os/centos-stream-9/images/pxeboot filter=lfs diff=lfs merge=lfs -text

data/pxe/okd/http_files/cluster_ssh_key.pub

@@ -0,0 +1 @@
+ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBx6bDylvC68cVpjKfEFtLQJ/dOFi6PVS2vsIOqPDJIc jeangab@liliane2

data/watchguard/pxe-http-files/.gitattributes

@@ -0,0 +1 @@
+slitaz/* filter=lfs diff=lfs merge=lfs -text

data/watchguard/pxe-http-files/boot.ipxe

@@ -0,0 +1,6 @@
+#!ipxe
+
+set base-url http://192.168.33.1:8080
+set hostfile ${base-url}/byMAC/01-${mac:hexhyp}.ipxe
+
+chain ${hostfile} || chain ${base-url}/default.ipxe

data/watchguard/pxe-http-files/byMAC/01-c4-62-37-01-bc-68.ipxe

@@ -0,0 +1,35 @@
+#!ipxe
+menu PXE Boot Menu - [${mac}]
+item okdinstallation  Install OKD
+item slitaz  Boot to Slitaz - old linux for debugging
+choose selected
+
+goto ${selected}
+
+:local
+exit
+
+#################################
+# okdinstallation
+#################################
+:okdinstallation
+set base-url http://192.168.33.1:8080
+set kernel-image fcos/fedora-coreos-39.20231101.3.0-live-kernel-x86_64
+set live-rootfs fcos/fedora-coreos-39.20231101.3.0-live-rootfs.x86_64.img
+set live-initramfs fcos/fedora-coreos-39.20231101.3.0-live-initramfs.x86_64.img
+set install-disk /dev/nvme0n1
+set ignition-file ncd0/master.ign
+
+kernel ${base-url}/${kernel-image} initrd=main coreos.live.rootfs_url=${base-url}/${live-rootfs} coreos.inst.install_dev=${install-disk} coreos.inst.ignition_url=${base-url}/${ignition-file}  ip=enp1s0:dhcp
+initrd --name main ${base-url}/${live-initramfs}
+boot
+
+#################################
+# slitaz
+#################################
+:slitaz
+set server_ip 192.168.33.1:8080
+set base_url http://${server_ip}/slitaz
+kernel ${base_url}/vmlinuz-2.6.37-slitaz rw root=/dev/null vga=788 initrd=rootfs.gz
+initrd ${base_url}/rootfs.gz
+boot

data/watchguard/pxe-http-files/byMAC/01-c4-62-37-02-60-fa.ipxe

@@ -0,0 +1,35 @@
+#!ipxe
+menu PXE Boot Menu - [${mac}]
+item okdinstallation  Install OKD
+item slitaz  Boot to Slitaz - old linux for debugging
+choose selected
+
+goto ${selected}
+
+:local
+exit
+
+#################################
+# okdinstallation
+#################################
+:okdinstallation
+set base-url http://192.168.33.1:8080
+set kernel-image fcos/fedora-coreos-39.20231101.3.0-live-kernel-x86_64
+set live-rootfs fcos/fedora-coreos-39.20231101.3.0-live-rootfs.x86_64.img
+set live-initramfs fcos/fedora-coreos-39.20231101.3.0-live-initramfs.x86_64.img
+set install-disk /dev/nvme0n1
+set ignition-file ncd0/master.ign
+
+kernel ${base-url}/${kernel-image} initrd=main coreos.live.rootfs_url=${base-url}/${live-rootfs} coreos.inst.install_dev=${install-disk} coreos.inst.ignition_url=${base-url}/${ignition-file}  ip=enp1s0:dhcp
+initrd --name main ${base-url}/${live-initramfs}
+boot
+
+#################################
+# slitaz
+#################################
+:slitaz
+set server_ip 192.168.33.1:8080
+set base_url http://${server_ip}/slitaz
+kernel ${base_url}/vmlinuz-2.6.37-slitaz rw root=/dev/null vga=788 initrd=rootfs.gz
+initrd ${base_url}/rootfs.gz
+boot

data/watchguard/pxe-http-files/byMAC/01-c4-62-37-02-61-0f.ipxe

@@ -0,0 +1,35 @@
+#!ipxe
+menu PXE Boot Menu - [${mac}]
+item okdinstallation  Install OKD
+item slitaz  Slitaz - an old linux image for debugging
+choose selected
+
+goto ${selected}
+
+:local
+exit
+
+#################################
+# okdinstallation
+#################################
+:okdinstallation
+set base-url http://192.168.33.1:8080
+set kernel-image fcos/fedora-coreos-39.20231101.3.0-live-kernel-x86_64
+set live-rootfs fcos/fedora-coreos-39.20231101.3.0-live-rootfs.x86_64.img
+set live-initramfs fcos/fedora-coreos-39.20231101.3.0-live-initramfs.x86_64.img
+set install-disk /dev/sda
+set ignition-file ncd0/worker.ign
+
+kernel ${base-url}/${kernel-image} initrd=main coreos.live.rootfs_url=${base-url}/${live-rootfs} coreos.inst.install_dev=${install-disk} coreos.inst.ignition_url=${base-url}/${ignition-file}  ip=enp1s0:dhcp
+initrd --name main ${base-url}/${live-initramfs}
+boot
+
+#################################
+# slitaz
+#################################
+:slitaz
+set server_ip 192.168.33.1:8080
+set base_url http://${server_ip}/slitaz
+kernel ${base_url}/vmlinuz-2.6.37-slitaz rw root=/dev/null vga=788 initrd=rootfs.gz
+initrd ${base_url}/rootfs.gz
+boot

data/watchguard/pxe-http-files/byMAC/01-c4-62-37-02-61-1a.ipxe

@@ -0,0 +1,35 @@
+#!ipxe
+menu PXE Boot Menu - [${mac}]
+item okdinstallation  Install OKD
+item slitaz  Boot to Slitaz - old linux for debugging
+choose selected
+
+goto ${selected}
+
+:local
+exit
+
+#################################
+# okdinstallation
+#################################
+:okdinstallation
+set base-url http://192.168.33.1:8080
+set kernel-image fcos/fedora-coreos-39.20231101.3.0-live-kernel-x86_64
+set live-rootfs fcos/fedora-coreos-39.20231101.3.0-live-rootfs.x86_64.img
+set live-initramfs fcos/fedora-coreos-39.20231101.3.0-live-initramfs.x86_64.img
+set install-disk /dev/nvme0n1
+set ignition-file ncd0/master.ign
+
+kernel ${base-url}/${kernel-image} initrd=main coreos.live.rootfs_url=${base-url}/${live-rootfs} coreos.inst.install_dev=${install-disk} coreos.inst.ignition_url=${base-url}/${ignition-file}  ip=enp1s0:dhcp
+initrd --name main ${base-url}/${live-initramfs}
+boot
+
+#################################
+# slitaz
+#################################
+:slitaz
+set server_ip 192.168.33.1:8080
+set base_url http://${server_ip}/slitaz
+kernel ${base_url}/vmlinuz-2.6.37-slitaz rw root=/dev/null vga=788 initrd=rootfs.gz
+initrd ${base_url}/rootfs.gz
+boot

data/watchguard/pxe-http-files/byMAC/01-c4-62-37-02-61-26.ipxe

@@ -0,0 +1,35 @@
+#!ipxe
+menu PXE Boot Menu - [${mac}]
+item okdinstallation  Install OKD
+item slitaz  Slitaz - an old linux image for debugging
+choose selected
+
+goto ${selected}
+
+:local
+exit
+
+#################################
+# okdinstallation
+#################################
+:okdinstallation
+set base-url http://192.168.33.1:8080
+set kernel-image fcos/fedora-coreos-39.20231101.3.0-live-kernel-x86_64
+set live-rootfs fcos/fedora-coreos-39.20231101.3.0-live-rootfs.x86_64.img
+set live-initramfs fcos/fedora-coreos-39.20231101.3.0-live-initramfs.x86_64.img
+set install-disk /dev/sda
+set ignition-file ncd0/worker.ign
+
+kernel ${base-url}/${kernel-image} initrd=main coreos.live.rootfs_url=${base-url}/${live-rootfs} coreos.inst.install_dev=${install-disk} coreos.inst.ignition_url=${base-url}/${ignition-file}  ip=enp1s0:dhcp
+initrd --name main ${base-url}/${live-initramfs}
+boot
+
+#################################
+# slitaz
+#################################
+:slitaz
+set server_ip 192.168.33.1:8080
+set base_url http://${server_ip}/slitaz
+kernel ${base_url}/vmlinuz-2.6.37-slitaz rw root=/dev/null vga=788 initrd=rootfs.gz
+initrd ${base_url}/rootfs.gz
+boot

data/watchguard/pxe-http-files/byMAC/01-c4-62-37-02-61-70.ipxe

@@ -0,0 +1,37 @@
+#!ipxe
+menu PXE Boot Menu - [${mac}]
+item okdinstallation  Install OKD
+item slitaz  Slitaz - an old linux image for debugging
+choose selected
+
+goto ${selected}
+
+:local
+exit
+# This is the bootstrap node
+# it will become wk2
+
+#################################
+# okdinstallation
+#################################
+:okdinstallation
+set base-url http://192.168.33.1:8080
+set kernel-image fcos/fedora-coreos-39.20231101.3.0-live-kernel-x86_64
+set live-rootfs fcos/fedora-coreos-39.20231101.3.0-live-rootfs.x86_64.img
+set live-initramfs fcos/fedora-coreos-39.20231101.3.0-live-initramfs.x86_64.img
+set install-disk /dev/sda
+set ignition-file ncd0/worker.ign
+
+kernel ${base-url}/${kernel-image} initrd=main coreos.live.rootfs_url=${base-url}/${live-rootfs} coreos.inst.install_dev=${install-disk} coreos.inst.ignition_url=${base-url}/${ignition-file}  ip=enp1s0:dhcp
+initrd --name main ${base-url}/${live-initramfs}
+boot
+
+#################################
+# slitaz
+#################################
+:slitaz
+set server_ip 192.168.33.1:8080
+set base_url http://${server_ip}/slitaz
+kernel ${base_url}/vmlinuz-2.6.37-slitaz rw root=/dev/null vga=788 initrd=rootfs.gz
+initrd ${base_url}/rootfs.gz
+boot

data/watchguard/pxe-http-files/default.ipxe

@@ -0,0 +1,71 @@
+#!ipxe
+menu PXE Boot Menu - [${mac}]
+item local  Boot from Hard Disk
+item slitaz Boot slitaz live environment [tux|root:root]
+#item ubuntu-server Ubuntu 24.04.1 live server
+#item ubuntu-desktop Ubuntu 24.04.1 desktop
+#item systemrescue System Rescue 11.03
+item memtest memtest
+#choose --default local --timeout 5000 selected
+choose selected
+
+goto ${selected}
+
+:local
+exit
+
+#################################
+# slitaz
+#################################
+:slitaz
+set server_ip 192.168.33.1:8080
+set base_url http://${server_ip}/slitaz
+kernel ${base_url}/vmlinuz-2.6.37-slitaz rw root=/dev/null vga=788 initrd=rootfs.gz
+initrd ${base_url}/rootfs.gz
+boot
+
+#################################
+# Ubuntu Server
+#################################
+:ubuntu-server
+set server_ip 192.168.33.1:8080
+set base_url http://${server_ip}/ubuntu/live-server-24.04.1
+
+kernel ${base_url}/vmlinuz ip=dhcp url=${base_url}/ubuntu-24.04.1-live-server-amd64.iso autoinstall ds=nocloud
+initrd ${base_url}/initrd
+boot
+
+#################################
+# Ubuntu Desktop
+#################################
+:ubuntu-desktop
+set server_ip 192.168.33.1:8080
+set base_url http://${server_ip}/ubuntu/desktop-24.04.1
+
+kernel ${base_url}/vmlinuz ip=dhcp url=${base_url}/ubuntu-24.04.1-desktop-amd64.iso autoinstall ds=nocloud
+initrd ${base_url}/initrd
+boot
+
+#################################
+# System Rescue
+#################################
+:systemrescue
+set base-url http://192.168.33.1:8080/systemrescue
+
+kernel ${base-url}/vmlinuz initrd=sysresccd.img boot=systemrescue docache
+initrd ${base-url}/sysresccd.img
+boot
+
+#################################
+# MemTest86 (BIOS/UEFI)
+#################################
+:memtest
+iseq ${platform} efi && goto memtest_efi || goto memtest_bios
+
+:memtest_efi
+kernel http://192.168.33.1:8080/memtest/memtest64.efi
+boot
+
+:memtest_bios
+kernel http://192.168.33.1:8080/memtest/memtest64.bin
+boot

data/watchguard/pxe-http-files/paul

@@ -1 +0,0 @@
-hey i am paul

demos/cncf-k8s-quebec-meetup-september-2025/.gitignore

@@ -0,0 +1,3 @@
+.terraform
+*.tfstate
+venv

demos/cncf-k8s-quebec-meetup-september-2025/README.md

@@ -0,0 +1,5 @@
+To build :
+
+```bash
+npx @marp-team/marp-cli@latest -w slides.md
+```

demos/cncf-k8s-quebec-meetup-september-2025/ansible/README.md

@@ -0,0 +1,9 @@
+To run this :
+
+```bash
+virtualenv venv
+source venv/bin/activate
+pip install ansible ansible-dev-tools
+ansible-lint download.yml
+ansible-playbook -i localhost download.yml
+```

demos/cncf-k8s-quebec-meetup-september-2025/ansible/download.yml

@@ -0,0 +1,8 @@
+- name: Test Ansible URL Validation
+  hosts: localhost
+  tasks:
+    - name: Download a file
+      ansible.builtin.get_url:
+        url: "http:/wikipedia.org/"
+        dest: "/tmp/ansible-test/wikipedia.html"
+        mode: '0900'