website-and-documentation/content/en/docs-old/v1/solution/design/proposal-stack-hydration.md
Stephan Lo 62999b41d0 feat(docs): restructure documentation with new framework and templates
- 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
2025-11-16 13:32:10 +01:00

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.