ADR: Default runtime for harmony workloads

This ADR proposes to use k3s as a default runtime on linux and k3d on other platforms supporting docker

adr/006-secret-management.md

@@ -5,6 +5,7 @@
 Proposed
 
 ### TODO :
+
 Before accepting this proposal we need to run a POC to validate this potential issue :
 
 **Keycloak Misuse**: Using Keycloak primarily as a secrets manager is inappropriate, as it's designed for identity and access management (IAM), not secrets management. This creates scalability and functionality limitations.

adr/007-default-runtime.md

@@ -0,0 +1,68 @@
+# Architecture Decision Record: Default Runtime for Managed Workloads**
+
+## Status
+
+Proposed
+
+## Context
+
+Our infrastructure orchestrator manages workloads that require a runtime environment for execution.
+
+**Requirements**
+
+- Cross platform
+- Supports running complex workloads (similar level of complexity to kubernetes)
+- Easy to install and setup
+- Low footprint
+- Well maintained
+- K8s compatibility a big plus
+
+When a user launches a project orchestrated by harmony it should run. End of story.
+
+This means that we need to be able to automatically install a runtime appropriate for our core use cases. As our context is mostly enterprise applications deployed on various flavors of kubernetes clusters, it is natural to move towards lightweight k8s distributions such as k3s, microk8s, minikube, etc.
+
+Now, the main use case where we want it to "just work" is when a developer (or user) clones a repository or downloads an application and wants to launch it locally with zero setup. This means that there is no container runtime installed, no kubernetes cluster, no assumption of libraries or tools installed.
+
+## Decision
+
+We selected **k3s as the default runtime** for managed workloads on Linux platforms and **k3d on Windows and MacOS**. Other platforms that do not support either k3s or docker are deemed out of scope.
+
+## Rationale
+
+- **Lightweight and Easy to Install:** K3s is designed to be a lightweight Kubernetes distribution, making it easy to install and run on resource-constrained environments, which aligns with our "zero setup" goal. K3d provides a similar experience for MacOS and Windows, leveraging Docker to create lightweight k3s clusters.
+- **Kubernetes Compatibility:** K3s is a certified Kubernetes distribution, ensuring compatibility with standard Kubernetes manifests and tools. This allows users to easily migrate workloads between our platform and other Kubernetes environments. K3d also provides this compatibility by running k3s in Docker containers.
+- **Low Resource Consumption:** K3s has a small footprint, minimizing the resource overhead on the host system. This is crucial for local development environments where resources are often limited. K3d shares this advantage as it runs k3s in containers, allowing for efficient resource utilization.
+- **Well-Maintained:** Rancher (now SUSE) actively maintains K3s, providing regular updates and security patches. This ensures the stability and security of our platform. K3d benefits from the active k3s community and its own dedicated maintainers.
+- **Suitable for Edge Computing:** While not our primary focus *now*, K3s's design makes it suitable for edge computing scenarios, providing a potential future expansion path.
+- **Single Binary:** K3s is packaged as a single binary, simplifying installation and management.
+- **Docker Dependency on Windows/MacOS acceptable:** While not ideal, the ubiquity of Docker Desktop on these platforms makes k3d a reasonable choice, as it leverages an existing dependency.
+
+## Consequences
+
+### Positive
+
+- **Simplified User Experience:** Users can quickly launch projects without needing to install and configure a complex runtime environment.
+- **Increased Developer Productivity:** Developers can focus on writing code rather than managing infrastructure.
+- **Consistent Environment:** Ensures a consistent runtime environment across different development machines.
+- **Reduced Support Burden:** Automating runtime setup reduces the support burden on the platform team.
+- **Future-Proofing:** Kubernetes compatibility provides a clear migration path to other Kubernetes environments.
+- **Enables local testing that mirrors production:** By using a k8s distribution locally, developers can test how their application will behave in a production k8s cluster.
+
+### Negative
+
+- **Platform Dependency:** K3s is primarily designed for Linux, requiring a different solution (k3d) for Windows and macOS. This adds complexity to our platform.
+- **Docker Dependency on Windows/MacOS:** k3d relies on Docker being installed. Users without Docker will need to install it. This could be a barrier to entry for some users.
+- **Potential Resource Conflicts:** While K3s is lightweight, it still consumes resources. Running multiple K3s instances (especially via k3d) can lead to resource contention on developer machines.
+- **Security Considerations:** As with any runtime environment, K3s and k3d introduce potential security vulnerabilities. We need to ensure that we keep them up-to-date with the latest security patches.
+- **Abstraction Leakage:** While we aim for a "zero setup" experience, users may still need to understand basic Kubernetes concepts to troubleshoot issues.
+
+## Alternatives considered
+
+- **Minikube:**  A popular option, but can be more resource-intensive than K3s.  Also, the driver model can be complex to manage across different operating systems.
+- **MicroK8s:** Another lightweight Kubernetes distribution, but K3s has a stronger focus on simplicity and ease of use.
+- **Docker Compose:**  Simpler than Kubernetes, but lacks the orchestration capabilities needed for complex workloads.  Also, doesn't align with our Kubernetes-centric approach.
+- **Podman Desktop:** An increasingly popular alternative to Docker Desktop, but k3d does not fully support it yet.
+- **Kind (Kubernetes in Docker):** Similar to k3d, but specifically designed for testing Kubernetes itself, rather than running general workloads.
+- **Relying on User-Provided Runtime:**  This would require users to install and configure their own runtime environment, which goes against our "zero setup" goal.  Increases support burden and leads to inconsistent environments.
+- **Virtual Machines (VMs):** Using VMs would provide isolation, but would be much more resource-intensive and slower to start than container-based solutions.
+

examples/lamp/src/main.rs

@@ -17,5 +17,8 @@ async fn main() {
         },
     };
 
-    Maestro::load_from_env().interpret(Box::new(lamp_stack)).await.unwrap();
+    Maestro::load_from_env()
+        .interpret(Box::new(lamp_stack))
+        .await
+        .unwrap();
 }