GitOps the Hard Way: Rebuilding a Source of Truth (Three Times)#

Radim Roška · ALTEPRO solutions (per slides)

• Why: The hardest problem in EVPN fabric automation is the data model, not the tooling — demonstrated by rebuilding the schema three times before it survived production. Directly relevant DC-fabric territory.
• What: A dual-DC EVPN/VXLAN fabric, ~40 Arista switches, automated from day one with AVD, Git and GitLab CI. The real work: extracting a coherent service model from a network that had no source of truth, discovering vendor-provided data models (AVD's) didn't fit their operational requirements, and building operator tooling (a CLI editor, validator, and search) so junior engineers could actually use the SOT. One year on, the ops team uses it daily; the biggest shift was in how they think about configuration, not speed.
• How: Two layers: a CRA service SOT capturing service intent, and a translator to the AVD data model — service identity is global while VLAN/VNI mapping is POD-local, which forced the separate abstraction. Day-2 pipeline: edit → commit → MR → validate → translate → build → deploy, with avd-editor/avd-validator/avd-finder as operator-facing tools.
• Where applicable: Arista/AVD-specific implementation at small-mid scale (40 switches, 2 DCs). The core lesson — service intent needs its own abstraction above the vendor model — generalizes to any fabric program.