Stephan Lo
f797af114b
Configure markdownlint with rules aligned to technical documentation standards and Docsy theme conventions. Design Decisions: - Enable core quality rules (heading hierarchy, consistent list styles) - Allow inline HTML for Docsy shortcodes and components - Permit bare URLs (common in technical documentation) - Make code block language hints optional (pragmatic for existing content) - Set maximum 2 consecutive blank lines (balanced readability) - Enforce single trailing newline (POSIX standard) - Use asterisk for unordered lists (consistency) - Allow 2-space list indentation (Markdown standard) Auto-fixed Issues: - Converted dash lists to asterisk lists (568 fixes) - Removed trailing spaces (211 fixes) - Added missing trailing newlines (74 fixes) - Added blank lines around lists and headings (100+ fixes) Remaining Style Warnings (intentionally accepted): - MD029: List numbering variations in meeting notes (75 instances) - MD036: Bold text for section headers in ADRs (13 instances) - MD025: Multiple H1 in notes/brainstorming docs (10 instances) - MD032/MD022: Minor spacing variations (15 instances) Test Results: ✅ Hugo build: 227 pages generated successfully ✅ HTML validation: No errors ✅ Link checking: All links valid (except dev-only livereload) ✅ Markdown linting: Only non-critical style warnings remain The configuration balances strict quality checks with pragmatic flexibility for diverse content types (documentation, ADRs, meeting notes, tutorials).
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.
|