YANG - Моделирование необязательных контейнеров

В настоящее время я работаю с YANG в рамках (устаревшего) проекта Python.

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

«Неизменный» фрагмент данных:

"namespace": {                      # Mandatory
    "management": {                 # Optional
        "interfaces": {             # Mandatory
            "m0": {                 # Optional
                "leaf1": "..."
            }
        }
    },
    "benchmark": {                  # Optional
        "interfaces": {             # Mandatory
            "b0": {                 # Optional
                "leaf1": "...",
                "leaf2": "..."
            },
            "b1": {                 # Optional
                "leaf1": "...",
                "leaf2": "..."
            }
        }
    }
}

Моя проблема в том, что все, что помечено как «необязательное» (в примере), будет смоделировано как контейнер, но кажется, что они не могут быть определены как необязательные (т.е. обязательные false;) в соответствии с RFC6020.

Поэтому я определил модель, использующую списки. Это означает, что некоторые узлы Python Dict (управление, тест, m0, b0, b1) теперь являются элементами списка и недоступны в текущем виде, например: data['namespace']['management']...

Модифицированный пример выглядит так:

"namespace": [
    {
        "desc": "management",
        "interfaces": [
            {
                "leaf1": "..."
            }
        ]
    },
    {
        "desc": "benchmark",
        "interfaces": [
            {
                "leaf1": "...",
                "leaf2": "..."
            },
            {
                "leaf1": "...",
                "leaf2": "..."
            }
        ]
    }
]

Описание (фрагмент из моей текущей) модели YANG:

list namespace {
    description "Namespace definitions.";
    key desc;

    leaf desc { type string; }

    uses leaf-definitions;

    list interfaces {
        key leaf1;
        uses leaf-definitions;
    }
}

Проверка прошла успешно, и преобразование данных (само по себе) не проблема, но в результате получается большая куча неработающего кода.

Это приводит к моему вопросу (ам):

  1. Правильно ли я понимаю, что контейнеры в YANG всегда обязательны?
  2. Может быть, есть другой способ смоделировать этот сценарий? (не нарушая "лишнего")

Я очень благодарен за ваш вклад, так как я новичок в YANG!


ietf-netmod-yang
person Trollokia    schedule 10.02.2017    source источник
comment
есть ли какая-то конкретная причина, по которой у вас есть оператор uses leaf-definitions; непосредственно в списке namespace вашей текущей модели YANG? Я думал, что leaf-definitions — это какая-то группировка, определяющая листья, необходимые для интерфейса, а не всё пространство имён.   -  person Piotr Babij    schedule 12.02.2017
comment
Нет. В первую очередь я хотел минимизировать пример, кроме того, заманчиво было сгруппировать большинство возможных листьев. Так что leaf-definitions — это всего лишь заполнитель. Но мой план состоит в том, чтобы использовать (по крайней мере) две группы для этой цели (одну для общих листьев пространства имен и одну для листьев интерфейса). Меня больше всего беспокоит объем дополнительной работы, связанной с переходом от контейнера к списку, который потребуется, чтобы снова заставить старый код работать.   -  person Trollokia    schedule 12.02.2017

Ответы (1)


arrow_upward
1
arrow_downward

Правильно ли я понимаю, что контейнеры в YANG всегда обязательны?

Наоборот. Они всегда необязательны, если только они не содержат обязательных узлов (обязательный лист, список или лист-список с минимальными элементами > 0 и т. д.). Другими словами, контейнеры наследуют это свойство от своих потомков. Это, конечно, относится только к контейнерам без присутствия. Контейнер присутствия с обязательными дочерними элементами не наследует это свойство, поскольку это противоречило бы его назначению (присутствию). Вероятно, вы пропустили определение обязательного узла в RFC6020:

  A mandatory node is one of:

  o  A leaf, choice, or anyxml node with a "mandatory" statement with
      the value "true".

  o  A list or leaf-list node with a "min-elements" statement with a
      value greater than zero.

  o  A container node without a "presence" statement, which has at
      least one mandatory node as a child.

Это уже должно быть полезно для вашего второго вопроса.

Может быть, есть другой способ смоделировать этот сценарий? (не нарушая "лишнего")

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

module mandatory-optional-branch {
  namespace "org:example:mandatory-optional-branch";
  prefix "mob";

  grouping leafs {
    leaf leaf1 {type string;}
    leaf leaf2 {type string;}
  }

  list namespace { // mandatory
    config false;
    min-elements 1;
    max-elements 1;
    container management { // optional by nature
      presence "I have mandatory children, but am not mandatory. Yay for me.
                Of course my presence should have some meaning.";
      list interfaces { // mandatory
        min-elements 1;
        max-elements 1;
        container m0 { // optional - no mandatory node children
          leaf leaf1 {type string;}
        }
      }
    }
    container benchmark { // optional by nature
      presence "Same as 'management' above.";
      list interfaces { // mandatory
        min-elements 1;
        max-elements 1;
        container b0 { // optional - no mandatory node children
          uses leafs;
        }
        container b1 { // optional - no mandatory node children
          uses leafs;
        }
      }
    }
  }
}
person predi    schedule 13.02.2017
comment
@Trollokia, я неправильно прочитал ваши исходные данные (следовательно, модель немного неверна), но это должно помочь вам начать. - person predi; 13.02.2017
comment
Преди спасибо! Это действительно заставляет меня начать - я видел определение обязательного узла (/контейнера) вчера, когда я перечитывал RFC, но был очень не уверен, может ли это быть решением. Я отчитаюсь. - person Trollokia; 13.02.2017
comment
На самом деле я использовал обязательные листья вниз по иерархии, но с presence даже это работало. Протестировал обе версии, успешно - Спасибо! - person Trollokia; 13.02.2017