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