NEP-0100: Resources

В рамках работ над управлением каналами появилась новая абстракция - ресурсы, которая позволяет адресовать произвольные сущности через нотацию <схема>:<id>[:<детализация>]. Таким образом, возможны указатели вида:

o:1234567789012345678901234 - Object
o:1234567789012345678901234:LINE1 - слот LINE1 объекта

Схемы ресурсов¶

Схема	Ресурс	Фомат
o	Объект	`o:<id объекта>` или `o:<id объекта>:<connection>`
mo	Managed Object	`o:<id MO>`
i	Interface	`i:<mo id>:<имя интерфейса>`
si	Sub interface	`si:<mo id>:<имя сабинтерфейса>`
p	Plain	`p:<текст>`, см [[#Тип ресурса plain]]
a	Administrative domain	`a:<ad id>`
s	Segment	`s:<segment id>`
c	Channel	`c:<channel id>`

Тип ресурса plain¶

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

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

Пути ресурсов¶

В большинстве случаев ресурсы образовывают иерархию и отдельный ресурс может являться частью более крупной группы. При этом часто возникает вопрос эффективного поиска всех ресурсов, входящих в выбранный. Для этого необходим полный путь к ресурсу (resource path).

Resource path является списком, содержащим все ресурсы по пути, начиная от самого общего и заканчивая конечным ресурсом.

Канонические пути resource path перечислены далее.

Объект¶

Cостоит из:

Список контейнеров - 0 или более ресурсов типа o для каждого контейнера на пути
Путь внутри ящика - 0 или более последовательностей:
1. o:<id объекта для модуля>
2. o:<id объекта для модуля>:<имя connection вниз>
Конечный элемент - только если финальной точкой является объект в inventory, а не его слот - типа o.

Пример1: Слот Gi2 модуля из 2 слота шасси, смонтированого в стойку, находяющуюся в PoP

o:<id pop>
o:<id стойки>
o:<id шасси>
o:<id шасси>:2
o:<id модуля>
o:<id модуля>:Gi2

Пример 2: Трансивер из слота Gi2 модуля из 2 слота шасси, смонтированого в стойку, находяющуюся в PoP

o:<id pop>
o:<id стойки>
o:<id шасси>
o:<id шасси>:2
o:<id модуля>
o:<id модуля>:Gi2
o:<id трансивера>

Administrative domain¶

Состоит из списка элементов типа a для всей иерархии по пути

Сегмент¶

Состоит из списка элементов типа s для всей иерархии по пути

Managed Object¶

Состоит из одного элемента типа mo

Интерфейс¶

Состоит из: 1. Managed object - mo:<mo id> 2. Список модулей - Опционально, часть object от шасси и до порта. 3. Ресурса интерфейса: i:<mo id>:<name>

Сабинтерфейс¶

Состоит из: 1. Managed object - mo:<mo id> 2. Список модулей - Опционально, часть object от шасси и до порта. 3. Ресурса интерфейса: i:<mo id>:<name> 4. Ресурса сабинтерфейса: si:<mo id>:<name>

Channel¶

Состоит из одного элемента c:<channel id>

В случае необходимости привязки к конретному entrypoint - используется дополнительная привязка к объектам/интерфейсам или сабинтерфейсам

API¶

Получение ресурса¶

Для получения ресурса из instance реализуется метод модели/документа.

def as_resource(self, part:str | None = None) -> str: ...

Получение resource path¶

Для получения resource path для instance или его части используется метод модели/документа.

def as_resource_path(self, part:str | None = None) -> list[str]: ...

Протокол resource¶

Необходим для задания типизации:

class Resource(Protocol):
    def as_resource(self, part:str | None = None) -> str: ...
    def as_resource_path(self, part:str | None = None) -> list[str]: ...