website-and-documentation/content/en/docs-old/v1/solution/design/proposal-local-deployment.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

969 B

title weight description
Agnostic EDF Deployment 2 The implementation of EDF must be kubernetes provider agnostic
  • Type: Proposal
  • Owner: Stephan Lo (stephan.lo@telekom.de)
  • Reviewers: EDF Architects
  • Status: Speculative, revision 0.1

Background

EDF is running as a controlplane - or let's say an orchestration plane, correct wording is still to be defined - in a kubernetes cluster. Right now we have at least ArgoCD as controller of manifests which we provide as CNOE stacks of packages and standalone packages.

Proposal

The implementation of EDF must be kubernetes provider agnostic. Thus each provider specific deployment dependency must be factored out into provider specific definitions or deployment procedures.

Local deployment

This implies that EDF must always be deployable into a local cluster, whereby by 'local' we mean a cluster which is under the full control of the platform engineer, e.g. a kind cluster on their laptop.