- Move all existing docs content (concepts, project, solution) to /docs/v1/ - Add legacy banner component to warn users about archived documentation - Create v1 index page with legacy notice and redirect guidance - Implement automatic banner display for all v1 paths - Preserve all original content for reference during migration This enables incremental content migration while maintaining access to original documentation.
28 lines
1 KiB
Markdown
28 lines
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.
|