Как выглядит идентификатор экземпляра в модели Янга? - PullRequest
Новая
       15

Как выглядит идентификатор экземпляра в модели Янга?

0 голосов
/ 24 марта 2020

Насколько я понимаю, тип идентификатора экземпляра имеет оператор XPath, который указывает на то, что какой-то узел является деревом. И что дальше? Как идентификатор экземпляра идентифицирует этот узел? Как применить идентификатор экземпляра к узлу, на который он указывает? Или я неправильно понял ... У меня также нет примеров, кроме найденных в Google, например 

    leaf instance-identifier-leaf {
        type instance-identifier;
    }

1 Ответ

0 голосов
/ 07 апреля 2020

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

Учитывая что данные YANG могут быть выражены в виде XML документа, то есть способ, которым вы «указываете» на указанный элемент c внутри, поэтому аналогичен «указанию» на указанный элемент c XML. Вы делаете это в XML с помощью XPath, который позволяет использовать

Вот пример: 

   container a {

      list b {
         key x;
         leaf x { type int8; }

         list c {
            key y;
            leaf y { type int8; }
         }
     }
  }

  leaf ref {
    type instance-identifier;
  }

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

<a>
  <b>
    <x>1</x>
  </b>
  <b>
    <x>5</x>
    <c>
      <y>1</y>
    </c>
    <c>
      <y>2</y>
    </c>
  </b>
  <b>
    <x>10</x>
    <c>
      <y>5</y>
    </c>
  </b>
</a>

Таким образом, у нас есть куча из списка записей, некоторые из них каскадно. Если бы вы представляли все эти узлы в xpath, вы получили бы список с: 

/a
/a/b[x=1]
/a/b[x=5]
/a/b[x=5]/c[y=1]
/a/b[x=5]/c[y=2]
/a/b[x=10]
/a/b[x=10]/c[y=5]

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

Последнее замечание: необязательно, чтобы узел, на который ссылается идентификатор экземпляра, действительно существовал в хранилище данных; у вас может быть идентификатор экземпляра, который указывает на несуществующий узел. Существует оператор yang (require-instance), который можно добавить в качестве подстановки оператора type, который позволяет контролировать, можно ли ссылаться только на существующие экземпляры или же можно принимать несуществующие.

Что касается формата значения, обратите внимание, что способ представления идентификатора экземпляра зависит от протокола, который вы используете. Идентификатор экземпляра в NETCONF отличается от идентификатора в RESTCONF (хотя они очень похожи). Можно представить, что CLI имеет собственный способ представления объектов YANG, например:

  • Узел данных определяется с помощью xpath / a / b [x = 5] / c [ y = 1]
  • В CLI этот адрес узла отображается как c -5-1 (только пример)
  • Если у вас был идентификатор экземпляра, указывающий на этот объект, его значением будет строка 'c -5-1' в CLI, но в NETCONF это все равно будет xpath.

Короче говоря, формат зависит от протокола, который вы используете.

...