- Archive old docs to docs-old/ for reference - Create new top-down documentation structure: * Platform Overview: purpose, audience, product structure * Components: individual platform components (Forgejo, Kubernetes, Backstage) * Getting Started: onboarding and quick start guides * Operations: deployment, monitoring, troubleshooting * Governance: ADRs, project history, compliance - Add DOCUMENTATION-GUIDE.md with writing guidelines and templates - Add component template (TEMPLATE.md) for consistent documentation - Simplify root README and move technical docs to doc/ folder - Update test configuration: * Exclude legacy content from markdown linting * Relax HTML validation for theme-generated content * Skip link checking for legacy content in test:links * Keep 'task test' clean for technical writers (100% pass) * Add 'task test:full' with comprehensive link checking - Update home page with corrected markdown syntax - Fix internal links in archived content BREAKING CHANGE: Documentation structure changed from flat to hierarchical top-down approach
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.
|