Compare commits
2 Commits
3097e6af67
...
564c00660b
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
564c00660b | ||
|
|
61a0cb5434 |
33
adr/000-ADR-Template.md
Normal file
33
adr/000-ADR-Template.md
Normal file
@ -0,0 +1,33 @@
|
|||||||
|
# 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
|
||||||
52
adr/009-helm-and-kustomize-handling.md
Normal file
52
adr/009-helm-and-kustomize-handling.md
Normal file
@ -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
|
||||||
Loading…
Reference in New Issue
Block a user