doc(architecture): added architectural decision of templated stacks
This commit is contained in:
parent
1b77a80563
commit
58da741bca
1 changed files with 28 additions and 0 deletions
28
content/en/docs/solution/design/proposal-stack-hydration.md
Normal file
28
content/en/docs/solution/design/proposal-stack-hydration.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
---
|
||||
title: Agnostic Stack Definition
|
||||
weight: 2
|
||||
description: The implementation of EDF stacks must be kubernetes provider agnostic by a templating/hydration mechanism
|
||||
---
|
||||
|
||||
* Type: Proposal
|
||||
* Owner: Stephan Lo (stephan.lo@telekom.de)
|
||||
* Reviewers: EDF Architects
|
||||
* Status: Speculative, revision 0.1
|
||||
|
||||
## Background
|
||||
|
||||
When booting and reconciling the 'final' stack exectuting orchestrator (here: ArgoCD) needs to get rendered (or hydrated) presentations of the manifests.
|
||||
|
||||
It is not possible or unwanted that the orchestrator itself resolves dependencies or configuration values.
|
||||
|
||||
## Proposal
|
||||
|
||||
The hydration takes place for all target clouds/kubernetes providers. There is no 'default' or 'special' setup, like the Kind version.
|
||||
|
||||
## Local development
|
||||
|
||||
This implies that in a development process there needs to be a build step hydrating the ArgoCD manifests for the targeted cloud.
|
||||
|
||||
## Reference
|
||||
|
||||
Discussion from Robert and Stephan-Pierre in the context of stack development - there should be an easy way to have locally changed stacks propagated into the local running platform.
|
||||
Loading…
Add table
Add a link
Reference in a new issue