28 lines
1.1 KiB
Markdown
28 lines
1.1 KiB
Markdown
|
---
|
||
|
|
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.
|