# Channel Controller

## Use case for ODU trail

1. Юзер выбирает клиентский порт на карте (не занятый)
2. Юзер выбирает тип ODU (если > 1)
3. Если уже проброшен ad-hoc канал, предлагаем использовать его
4. Юзер выбирает карту для другого конца канала
6. Система показывает список портов, до которых технически возможно дотянуться, или выдает сообщение о нехватке OTU. OTU пригодно для использования только если в него может быть размещено исходное ODU с заданного порта.
7. Юзер выбирает порт для другого конца канала
8. Юзер выбирает размещение ODU в OTU

Реакция системы:

* Создаем канал.
* Создаем endpoint'ы в домене ODU для 2 клиентских портов и подцепляем к каналу.
* Создаем задачу для runner с 2 job на настройку кроссировок на двух ADM картах.

## Use case for OTU trail

Для создания канала возможно задать дополнительные ограничения:

1. Список объектов (платы, шасси, PoP, группы), через которые должен проходить канал
2. Список объектов, через которые запрещено проводить канал

Сценарий:

1. Юзер выбирает линейный порт на карте (не занятый)
2. Юзер выбирает тип OTU (если > 1)
3. Юзер выбирает частотные характеристики. При этом необходимо учитывать:
* Возможности трансивера
* Использование частот на всех ROADM, до которых теоретически можно дотянуться с данного порта (с учетом возможности переконфигурации)
5. Юзер выбирает объект, где должен находиться второй конец канала. Объект может быть как картой, так и шасси, PoP или группой.
6. Система трассирует оптическую сеть и находит линейные порты, которые попадают под критерий. При этом для каждой возможной трассы указывается, реализована ли она полностью, или требуется конфигурация ROADM.
7. Юзер выбирает второй линейный порт

Реакция системы:
* Создаем канал.
* Создаем endpoint'ы в домене OTU для 2 клиентских портов и подцепляем к каналу, ставим discriminator lambda с выбранными частотами.
* Создаем задачу для runner с 2 job на настройку OTU на двух ADM картах. В случае необходимости настройки ROADM формируем job на кроссировку.