Model Driven Programmability

Так что же это такое? Ведомая моделью программируемость? Теперь, после двух статей, нам хватит пары минут, чтобы разобраться что это такое.

Давайте вернёмся к 4-й части АДСМ, где я использовал позаимствованную у Дмитрия Тесля картинку.

Источник: dteslya.engineer/network_automaiton_101

Она ведь очень понятная? Inventory, Git с шаблонами конфигурации, рендер, валидация, применение.

Где закопаны два мешка с человеко-неделями? Под шаблонами с генераторами и под системами применения конфигурации.

Со вторым пытаются бороться NETCONF, RESTCONF, gNMI.

А с первым - модели.

Проблема в том, что шаблоны мы составляем руками на основе изучения документации, интерфейса коробки и действуем методом проб и ошибок, вообще-то. Если нужна проверка типов, диапазонов, если меняется иерархия - будьте добры сами всё это написать и обработать. И, окончив, уехать в сумасшедший дом, учить друзей джинджа-программированию.

Model Driven меняет картину следующим образом:

Не могу найти, откуда брал эту картинку.

Здесь шаблоны конфигурации заменяются на YANG-модель (в данном случае OpenConfig).

Из инвентарки (топологии) и этих моделей рендерится конфиг, который с помощью RPC (тут gRPC) прогружается на коробку.

Model Driven означает тут, что мы

А) не думаем (или думаем меньше) про иерархию, типы данных. Перестаём мыслить тегами XML.

Б) Модель определяет, как будет выглядеть конфигурация, как с ней работать.

В) Использование точно такой же модели на устройстве гарантирует, что отправленное нами, будет принято и валидно на той стороне, коль скоро оно валидно на этой.

Иными словами именно модель управляет тем, как мы и железо будет работать с конфигурацией.

Вот и вся суть.