Stephan Lo
62999b41d0
- 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
1 KiB
1 KiB
| title | weight | description |
|---|---|---|
| Agnostic Stack Definition | 2 | 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.