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