# Доработка СОВЫ

## Заливка конфига
Необходимо реализовать функционал заливки конфигурации на оборудовании.

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

В зависимости от оборудования, файл конфигурации должен либо закачиваться
на оборудование и применяться атомарно, либо при помощи специальных команд
копируется с внешних серверов по протоколам HTTP/HTTPS, FTP, TFTP,
и также атомарно применяться.

Так как система поддерживает работу с пересекающимися адресными пространствами управления, необходимо иметь возможность разместить несколько provisioning cluster'ов (в вырожденном случае - по одному или более на каждый пул.)

Каждый provisioning cluster состоит из frontend (в виде open-source компонент, реализующих необходимые протоколы) и backend, через который система может загружать и удалять файлы (Рассмотреть возможность использования протоколов WebDAV или S3).

Процесс заливки конфига состоит из нескольких стадий:

1. Формирование файла конфига
2. Загрузка файла на provisioning cluster или на оборудование напрямую.
3. Запуск команды загрузки/активации конфига.

Целесообразно реализовать загрузку через сценарии оркестратора.

Необходимо реализовать:

1. Интерфейс IUploadConfig для скриптов.
2. Соотвествующие скрипты upload_config для основных платформ.
3. Разработать настройки для привязки provisioning-серверов к пулам или группам объектов.
4. Создание сценариев оркестратора для заливки конфига.
5. Кнопку в UI просмотра конфига, который заливает выбранную ревизию конфига.

> 3/161 пункта требований

## Заливка софта

Похож на заливку конфига, но необходимо учитывать возможные ограничения на миграции между версиями. Обновление софта также целесообразно реализовать через сценарии оркестратора.

Необходимо реализовать:

1. Интерфейс IUpdateFirmware, необходимо учитывать, что прошивка может состоять из отдельных компонент, кроме того, может существовать отдельная прошивка для bootloader'а.
2. Соответсвующие скрипты update_firmware для основных платформ.
3. Реализовать коллекцию inv.firmware для переноса данных между системами.
4. Доработать структуру Firmware для описания ограничений.
5. Реализовать кнопку обновления софта в Managed Object.
6. Реализовать UI для планирования массового обновления софта.
7. Реализовать сценарии для массового обновления софта с учетом топологии.
8. На перспективу - A/B тестирование.

> 12/161 пунктов требований

## NTP Diagnostics

Необходимо реализовать Object Diagnostic для проверки, что на оборудовании настроена синхронизация NTP с необходимыми серверами и сессии находятся в синхронизированном состоянии.

Необходимо реализовать:
1. Интерфейс IGetNTPStatus
2. Скрипты get_ntp_status для основных платформ
3. Привязку оборудования к NTP серверам (resource group?)
4. Диагностику NTP

> 3/161 пункттов требований

## Фасады оборудования (сделано)

Реализовать inventory plugin для просмотра фасада оборудования (включая установленные модули). Необходимо отображать вид спереди и вид сзади.

Предлагается в качестве основного формата использовать SVG, на первое время для редактирования использовать Boxy SVG или Inkscape.

Необходимо:
1. Описать соглашения по разметке слотов и индикаторов в общем SVG. i.e. специфичные id вроде `id="noc-slot-<name>"`. Дополнительные data attribute должны указывать ориентацию фасада вложенного объекта (одна и та же карта может стоять вертикально и горизонтально в зависимости от шасси). Отдельно описать лампочки и индикаторы. Фактически, необходим простой DSL.
2. Реализовать валидатороры, которые проверяют, что все слоты размечены
3. Реализовать виртуальные объекты - заглушки (placeholder), которые не существуют как отдельные объекты inventory, но отображаются, когда слот пуст. Возможно, что placeholder - просто фасад без объекта.
4. В секции slot объекта добавить опциональный аттрибут placeholder
5. Коллекция или пакет для фасадов, которые поставляются с системой.

Перспектива:

1. Встроенный редактор фасадов.

Вопросы:

* Хранить в коллекциях или пакетах?
* Общее со стенсилами?

## Физические карты/планы

Любая группа в inventory может содержать план, состоящий из загружаемой подложки, на которой размещаются вложенные объекты.
При этом должны отображаться связи между объектами. Необходимо предусмотреть фильтр показа объектов и связей по функциональным "слоям" (силовые, слаботочка, оптика, ....). Карты должны быть "живыми", то есть менять свое состояние в зависимости от метрик.

Оформить в виде inventory plugin.

Применения:

* Функциональные схемы ad-hoc
* План размещения стоек в зале

Мысли:
* Использовать model interface [plan](https://getnoc.com/model-interfaces-reference/plan/)

## Universal Event Logging

Общая структура в ClickHouse с фиксацией значимых событий, применимо к произвольному ресурсу системы. Audit trail на стероидах.

Необходиимо реализовать структуру данных и API, после чего начать расставлять события в коде.

> 10/168 пунктов требований

## Cross discovery

Строить link между line портами ADM на основании существующих кроссировок.

## NBI/Datastream Health endpoint

@todo: Поправить

Необходимо реализовать простейший NBI endpoint /api/nbi/health,
который могут дергать внешние системы для проверки связности и работоспособности NBI.

Запрос:

GET /api/nbi/healh

Нормальный ответ:

200 OK

{
    "status": true
}

NB: Все-таки требуется отдавать статус сервисов