Compare commits
No commits in common. "564c00660bb697e6c1b0a4b0b13864a9242b2e30" and "3097e6af67eee5a6a3857f4833c4cc7e66f51388" have entirely different histories.
564c00660b
...
3097e6af67
@ -1,33 +0,0 @@
|
|||||||
# Architecture Decision Record: \<Title\>
|
|
||||||
|
|
||||||
Name: \<Name\>
|
|
||||||
|
|
||||||
Initial Date: \<Date\>
|
|
||||||
|
|
||||||
Last Updated Date: \<Date\>
|
|
||||||
|
|
||||||
## Status
|
|
||||||
|
|
||||||
Proposed/Pending/Accepted/Implemented
|
|
||||||
|
|
||||||
## Context
|
|
||||||
|
|
||||||
The problem, background, the "why" behind this decision/discussion
|
|
||||||
|
|
||||||
## Decision
|
|
||||||
|
|
||||||
Proposed solution to the problem
|
|
||||||
|
|
||||||
## Rationale
|
|
||||||
|
|
||||||
Reasoning behind the decision
|
|
||||||
|
|
||||||
## Consequences
|
|
||||||
|
|
||||||
Pros/Cons of chosen solution
|
|
||||||
|
|
||||||
## Alternatives considered
|
|
||||||
|
|
||||||
Pros/Cons of various proposed solutions considered
|
|
||||||
|
|
||||||
## Additional Notes
|
|
||||||
@ -1,52 +0,0 @@
|
|||||||
# 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
|
|
||||||
Loading…
Reference in New Issue
Block a user