7.2 KiB

Raw Blame History

Mermaid Diagram Rendering Test

Test file to verify Gitea renders mermaid diagrams correctly. Delete this file after confirming.

Style Guidelines

All diagrams in this project follow a consistent style based on semantic color-coding by element role, color-blind-safe colors (Okabe-Ito derived), and minimal text per node.

Color palette (5 semantic colors + 1 neutral):

Role	Color	Hex	Node shape
Cluster node / VM	Teal	`#009E73`	Rectangle `["..."]`
Instance / container	Sky blue	`#56B4E9`	Rectangle `["..."]`
Network infrastructure	Blue	`#0072B2`	Rounded `("...")`
Load balancer / proxy	Amber	`#E69F00`	Rectangle `["..."]`
Management / control	Mauve	`#CC79A7`	Rectangle `["..."]`
External / entry point	Light gray	`#f5f5f5`	Stadium `(["..."])`

Subgraph fills: light tint of the dominant role color, darker stroke.

Rules:

Max 2 lines of text per node (name + one detail). Move specs to tables.
Top-down (TD) for hierarchies; left-right (LR) for lateral/peer relationships.
Solid arrows (-->) for data/traffic; dashed (-.->) for control/management.
Use classDef for styling, never per-node style statements.
No emojis or unicode symbols in labels (renderer compatibility).
Edge labels: 1-3 words max, only when relationship isn't obvious.

Test 1: HAProxy Architecture

Original: notes/haproxy-guide.md

flowchart TD
    client(["Client / LAN"])
    vip["VIP 192.168.103.200"]
    ovnlb("OVN Load Balancer")
    ha1["HAProxy 01\n10.10.10.50"]
    ha2["HAProxy 02\n10.10.10.51"]
    ng1["nginx-01 · .60"]
    ng2["nginx-02 · .61"]
    ng3["nginx-03 · .62"]

    client --> vip
    vip --> ovnlb
    ovnlb --> ha1 & ha2
    ha1 & ha2 --> ng1 & ng2 & ng3

    classDef external fill:#f5f5f5,color:#333,stroke:#999
    classDef network fill:#0072B2,color:#fff,stroke:#005a8e
    classDef lb fill:#E69F00,color:#fff,stroke:#b87d00
    classDef instance fill:#56B4E9,color:#fff,stroke:#3a8fbf

    class client external
    class vip,ovnlb network
    class ha1,ha2 lb
    class ng1,ng2,ng3 instance

Test 2: Bridge Topology

Original: notes/networking-guide.md

flowchart TD
    subgraph node1["Node 1 · net-node-01"]
        c1["c1 · .202"] & c2["c2 · .40"] --- br1("incusbr0\n10.0.0.1/24")
        br1 --> nat1["NAT · 192.168.1.209"]
    end

    subgraph node2["Node 2 · net-node-02"]
        c3["c3 · .52"] --- br2("incusbr0\n10.0.0.1/24")
        br2 --> nat2["NAT · 192.168.1.150"]
    end

    nat1 & nat2 --- lan(("LAN\n192.168.1.0/24"))

    classDef instance fill:#56B4E9,color:#fff,stroke:#3a8fbf
    classDef network fill:#0072B2,color:#fff,stroke:#005a8e
    classDef node fill:#009E73,color:#fff,stroke:#007a5e

    class c1,c2,c3 instance
    class br1,br2,lan network
    class nat1,nat2 node

    style node1 fill:#e6f5f0,stroke:#009E73
    style node2 fill:#e6f5f0,stroke:#009E73

Each node has its own bridge with the same subnet (10.0.0.1/24). The bridges are not connected to each other — cross-node traffic fails.

Test 3: OVN Topology

Original: notes/networking-guide.md

flowchart TD
    subgraph cp["OVN Control Plane"]
        ovnc["ovn-central\nNB :6641 · SB :6642"]
    end

    subgraph n1["Node 1 · net-node-01"]
        ctrl1["ovn-controller"] ~~~ ls1
        c1["c1 · .2"] & c2["c2 · .3"] --- ls1("logical switch\n10.10.10.0/24")
    end

    subgraph n2["Node 2 · net-node-02"]
        ctrl2["ovn-controller"] ~~~ ls2
        c3["c3 · .4"] --- ls2("logical switch\n10.10.10.0/24")
    end

    subgraph n3["Node 3 · net-node-03"]
        ctrl3["ovn-controller"] ~~~ ls3
        c4["c4 · .5"] --- ls3("logical switch\n10.10.10.0/24")
    end

    ovnc -.-> ctrl1 & ctrl2 & ctrl3

    ls1 <-->|Geneve| ls2
    ls2 <-->|Geneve| ls3
    ls1 <-->|Geneve| ls3

    n1 & n2 & n3 --- lan(("LAN\n192.168.1.0/24"))

    classDef mgmt fill:#CC79A7,color:#fff,stroke:#a36088
    classDef instance fill:#56B4E9,color:#fff,stroke:#3a8fbf
    classDef network fill:#0072B2,color:#fff,stroke:#005a8e
    classDef node fill:#009E73,color:#fff,stroke:#007a5e

    class ovnc mgmt
    class ctrl1,ctrl2,ctrl3 node
    class c1,c2,c3,c4 instance
    class ls1,ls2,ls3,lan network

    style cp fill:#f5e6f0,stroke:#CC79A7
    style n1 fill:#e6f5f0,stroke:#009E73
    style n2 fill:#e6f5f0,stroke:#009E73
    style n3 fill:#e6f5f0,stroke:#009E73

All instances share a single logical switch connected via Geneve tunnels. The control plane (dashed lines) manages the data plane (solid lines).

Test 4: Geneve Tunnel Mesh

Original: notes/ovn-deep-dive.md

graph LR
    n1(("oc-node-01\n.140"))
    n2(("oc-node-02\n.141"))
    n3(("oc-node-03\n.142"))

    n1 <-->|"Geneve 6081"| n2
    n2 <-->|"Geneve 6081"| n3
    n1 <-->|"Geneve 6081"| n3

    classDef chassis fill:#009E73,color:#fff,stroke:#007a5e

    class n1,n2,n3 chassis

Full mesh — every pair has a Geneve tunnel (UDP 6081) with BFD health monitoring. Tunnel keys are set per-packet from the OVN datapath.

Test 5: OVS Bridge Architecture