{"id":28569623,"url":"https://github.com/abilian/nephele-deploy","last_synced_at":"2026-01-20T16:28:29.615Z","repository":{"id":293475591,"uuid":"983961394","full_name":"abilian/nephele-deploy","owner":"abilian","description":"Deployment scripts for NEPHELE / SMO (using PyInfra)","archived":false,"fork":false,"pushed_at":"2025-08-14T13:33:26.000Z","size":475,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-08-23T10:35:53.933Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/abilian.png","metadata":{"files":{"readme":"README-kind.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2025-05-15T07:21:38.000Z","updated_at":"2025-08-14T13:33:29.000Z","dependencies_parsed_at":null,"dependency_job_id":"c11ff7c7-e74b-40db-937e-f4bd2d47d95a","html_url":"https://github.com/abilian/nephele-deploy","commit_stats":null,"previous_names":["abilian/nephele-deploy"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/abilian/nephele-deploy","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/abilian%2Fnephele-deploy","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/abilian%2Fnephele-deploy/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/abilian%2Fnephele-deploy/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/abilian%2Fnephele-deploy/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/abilian","download_url":"https://codeload.github.com/abilian/nephele-deploy/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/abilian%2Fnephele-deploy/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28607114,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-20T16:10:39.856Z","status":"ssl_error","status_checked_at":"2026-01-20T16:10:39.493Z","response_time":117,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-06-10T17:15:17.173Z","updated_at":"2026-01-20T16:28:29.601Z","avatar_url":"https://github.com/abilian.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Testbed Scenarios for KinD\n\nThis document outlines the various automated deployment scenarios available within this repository, all of which use `pyinfra` to provision a testbed environment based on KinD (Kubernetes in Docker). Each scenario is self-contained within a `kind-scripts-*` directory and is designed to test a specific aspect of the SMO platform, from basic federation to advanced application demonstrations.\n\n## 1. Foundational Testbed (`kind-scripts`)\n\nThis is deployment is designed to set up the full H3NI testbed environment as described in the main `README.md`. It creates the foundational infrastructure upon which most demonstrations are built.\n\n*   **Goal:** To provision a complete, multi-cluster Kubernetes lab managed by Karmada, including a full observability stack and the necessary application artifacts for the Brussels Demo.\n*   **Entrypoint:** `make deploy-kind`\n*   **Key Components \u0026 Sequence:**\n    1.  **Server Setup (`0-setup-server.py`):** Prepares the host by installing Docker, Go, `uv`, and other base dependencies. It also starts a local Docker container registry.\n    2.  **Karmada Control Plane (`1-deploy-karmada-on-kind.py`):** Deploys a KinD cluster named `karmada-cluster` to serve as the federation host and installs the Karmada control plane components into it.\n    3.  **Monitoring Stack (`2-`, `3-`, `4-*.py`):** Installs the `kube-prometheus-stack` via Helm into the host cluster and applies the necessary Custom Resource Definitions (CRDs) to the Karmada control plane, enabling federated monitoring. A Metrics Server is also deployed.\n    4.  **Member Cluster (`6-install-some-kind-cluster.py`):** Deploys a second KinD cluster named `bxl-cluster` to act as a workload cluster that will be managed by Karmada.\n    5.  **Demo Application Build (`7-build-bxl-demo-local-kind.py`):** Clones the original SMO project, builds the container images for the \"Brussels Demo,\" and pushes them to the local Docker registry.\n\nThis scenario results in a ready-state testbed but does not deploy the final application, leaving that step for the specific demo scenarios.\n\n## 2. Karmada Federation Test with Nginx (`kind-scripts-demo0` / `kind-scripts-karmada-nginx`)\n\nThis scenario is designed to verify the core multi-cluster scheduling capabilities of Karmada with a simple, well-known application. It uses the official Karmada setup scripts to create a multi-member cluster environment.\n\n*   **Goal:** To demonstrate that a standard Kubernetes workload (Nginx) can be deployed to a member cluster via the Karmada control plane using a `PropagationPolicy`.\n*   **Entrypoint:** `make deploy-demo0` (which executes `make deploy-karmada-nginx` from the `kind-scripts-demo0/Makefile`)\n*   **Key Components \u0026 Sequence:**\n    1.  **Full Karmada Environment (`4-install-kubectl-karmada.py`):** Deploys a complete Karmada setup using the official `local-up-karmada.sh` script. This creates a host cluster (`karmada-host`) and multiple member clusters (`member1`, `member2`, `member3`).\n    2.  **Prometheus on Members (`5-install-prometheus-members.py`):** Installs a basic Prometheus instance on each member cluster to test federated observability where members push metrics to a central host.\n    3.  **Nginx Deployment (`13-deploy-nginx.py`):**\n        *   Creates a standard Nginx `Deployment` manifest.\n        *   Creates a Karmada `PropagationPolicy` that targets the Nginx deployment and schedules it to run on `member1`.\n        *   Applies both manifests to the Karmada control plane.\n        *   Verifies that the Nginx pods are successfully running on the `member1` cluster and exposes the service for access.\n\nThis scenario provides a clean and simple validation of the entire federation and networking stack.\n\n## 3. The \"Brussels Demo\" (`kind-scripts-demo-bxl` / `kind-scripts-demo1`)\n\nThis is an end-to-end demonstration, deploying the full \"Brussels Demo\" application (from the original SMO) onto the Karmada testbed. Two versions of this demo exist, showcasing the project's evolution.\n\n*   **Goal:** To showcase the full capabilities of the SMO, including HDAG artifact management, service placement, and interaction with a federated monitoring stack.\n*   **Entrypoint:** `make deploy-bxl` (for the original SMO) or `make deploy-demo1` (for the refactored SMO Monorepo).\n*   **Key Components \u0026 Sequence:**\n    1.  **Full Karmada \u0026 Prometheus Setup:** Scripts deploy a complete multi-cluster environment with a host, multiple members, and a federated Prometheus stack. A key step is `8-merge-kube-configs.py`, which consolidates all cluster credentials into a single `karmada-apiserver.config` file for the SMO to use.\n    2.  **SMO Installation:**\n        *   **Original SMO (`10-install-nephele-smo.py`):** Clones the original `nephele-project/smo` repository, applies patches for KinD compatibility, configures it, and starts it via `docker-compose`.\n        *   **SMO Monorepo (`0-2-install-smo-cli-monorepo.py`):** Clones the `smo-monorepo`, builds the `smo-cli`, and configures it.\n    3.  **Brussels Demo Deployment (`12-install-bxl-demo.py` or `13-demo-bxl.py`):** These scripts automate the final steps from the Brussels Demo `README`:\n        *   It builds and pushes the demo's container images.\n        *   It packages the Helm charts and HDAG descriptor into OCI artifacts using `hdarctl`.\n        *   It pushes these artifacts to the local registry.\n        *   Finally, it calls the running SMO's REST API (or `smo-cli`) to deploy the application graph.\n\nThis scenario validates the entire toolchain and serves as the primary demonstration of the project's orchestration capabilities, with `demo1` representing the newer, CLI-driven approach.\n\n## 4. GPU Offloading Demo (`kind-scripts-demo2`)\n\nThis scenario is specifically designed to test the SMO's resource-aware placement capabilities, focusing on workloads that require specialized hardware like GPUs.\n\n*   **Goal:** To demonstrate that the SMO's placement algorithm can correctly identify and deploy a service to a cluster with GPU capabilities while placing non-GPU services on standard clusters.\n*   **Entrypoint:** `make deploy-demo2`\n*   **Key Components \u0026 Sequence:**\n    1.  **Testbed \u0026 SMO Monorepo Setup:** The initial scripts set up the standard Karmada and Prometheus environment and install the `smo-cli` from the `smo-monorepo`.\n    2.  **GPU Demo Deployment (`14-demo-gpu.py`):** This script uses the `h3ni-demos/2-gpu-offloading-demo` application. It builds and packages an application graph containing two services:\n        *   `ml-inference`: An application that explicitly requires a GPU in its HDAG descriptor.\n        *   `web-frontend`: A standard web application with no special hardware requirements.\n    3.  It then uses `smo-cli graph deploy` to submit the graph to the SMO. The validation consists of using `smo-cli graph describe` to confirm that the `ml-inference` service was placed on a (simulated) GPU-enabled cluster and the `web-frontend` on another.\n\n## 5. Autoscaling Demo (`kind-scripts-demo3`)\n\nThis scenario showcases the dynamic, metrics-driven autoscaling feature that has been integrated into the SMO.\n\n*   **Goal:** To demonstrate that the SMO can automatically scale a deployed service up and down based on real-time request rates gathered from Prometheus.\n*   **Entrypoint:** `make deploy-demo3`\n*   **Key Components \u0026 Sequence:**\n    1.  **Testbed \u0026 SMO Monorepo Setup:** The environment is prepared with Karmada, Prometheus, and the `smo-cli` (checked out from the `scaling` branch).\n    2.  **Autoscaling Demo Deployment (`15-demo-autoscaling.py`):** This script uses the `h3ni-demos/3-autoscaling-demo` application. It deploys an initial application graph.\n    3.  **Triggering the Scaler:** After deployment, the scenario uses the `smo-cli scaler run` command. This command continuously polls Prometheus for metrics (like HTTP requests per second) and compares them against predefined thresholds to automatically increase or decrease the number of replicas for a target service.\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fabilian%2Fnephele-deploy","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fabilian%2Fnephele-deploy","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fabilian%2Fnephele-deploy/lists"}