WIP

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

@@ -0,0 +1,52 @@
+# Architecture Decision Record: Helm and Kustomize Handling
+
+Name: Taha Hawa
+
+Initial Date: 2025-04-15
+
+Last Updated Date: 2025-04-15
+
+## Status
+
+Proposed
+
+## Context
+
+We need to find a way to handle Helm charts and deploy them to a Kubernetes cluster. Helm has a lot of extra functionality that we may or may not need. Kustomize handles Helm charts by inflating them and applying them as vanilla Kubernetes yaml. How should Harmony handle it?
+
+## Decision
+
+In order to move quickly and efficiently, Harmony should handle Helm charts similarly to how Kustomize does: invoke Helm to inflate/render the charts with the needed inputs, and deploy the rendered artifacts to Kubernetes as if it were vanilla manifests.
+
+## Rationale
+
+
+## Consequences
+
+Pros:
+- Much easier (and faster) than implementing all of Helm's featureset
+- Re-use code from K8sResource already present in Harmony
+- Harmony retains more control over how the deployment goes after rendering (i.e. can act like Kustomize, or leverage Kustomize itself to modify deployments after rendering/inflation)
+- Reduce (unstable) surface of dealing with Helm binary
+
+Cons:
+- Lose some Helm functionality
+- Potential lose some compatibility with Helm
+
+## Alternatives considered
+
+- Implement Helm fully
+    - Pros:
+        - Retain full compatibility with Helm as a tool
+        - Retain full functionality of Helm
+    - Cons:
+        - Longer dev time
+        - More complex integration
+        - Dealing with larger (unstable) surface of Helm as a binary
+- Leverage Kustomize to deal with Helm charts
+    - Pros:
+        - 
+    - Cons:
+        -
+
+## Additional Notes