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