You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 22
Next »
The following study describes extending YANG language statements to allow customization of models.
References:
YANG Language
- The YANG language provides us the ability to define and model configurations and state data by defining YANG modules
- Modules contain a sequence of statements
- Statement syntax is either of the following :
- statement = keyword [argument] ;
- statement = keyword [argument] { <substatement(s)..> } ;
* argument can be zero or one depending on the statement
* argument is a string
- An XML-based equivalent version of YANG is called YIN
- YANG uses a tree to define the hierarchy of data wherein each ‘node’ has a value or/and a set of child nodes
- 4 types of nodes
container nodes
- list nodes
Sample YANG (stores.yang) | Statements and Description |
---|
module stores {
yang-version 1.1;
namespace "org:onap:ccsdk:sample";
prefix book-store;
revision "2020-09-15" {
description
"Sample Model";
}
typedef year {
type uint16 {
range "1000..9999";
}
}
container bookstore {
leaf bookstore-name {
type string;
}
list categories {
key "code";
leaf code {
type string;
}
leaf name {
type string;
}
list books {
key title;
leaf title {
type string;
}
leaf-list authors {
type string;
}
}
}
}
}
| module Statement see example from Line 1 - YANG language defines models with modules and submodules
- Takes one argument (module name) which is the identifier
- Groups all statements that belong to the module
- This module example contains the following statements for header information:
see examples from Lines 2-16 - yang-version statement
- namespace statement prefix statement
- revision statements
typedef Statement see example from Line 12 - a statement that allows a new type to be defined based on a base type which is a YANG built-in type
container Statement see example from Line 18 - defines interior (container node) in the schema tree
- only contains child nodes, has no value
- child nodes can be a leaf, lists, containers and leaf-lists
leaf Statement see example from Line 27 - defines a leaf node in the schema tree
- its only one argument is the identifier
- has no child nodes, has one value of a particular type
- 'type statement' is mandatory
- See optional substatements available in (Section 7.6 https://www.hjp.at/doc/rfc/rfc6020.html#sec_1)
list Statement see example from Line 35 - defines an interior data node (list node) in the schema tree
- its only one argument is the identifier
- follows a block of substatements:
- mandatory substatements:
leaf-list Statement see example from Line 41 - array of leaf nodes
- one value of a particular type per leaf
- its only one argument is the identifier
|
Figure 1.1 Schema tree of module 'stores'
module: stores
+--rw bookstore
+--rw bookstore-name? string
+--rw categories* [code]
+--rw code string
+--rw name? string
+--rw books* [title]
+--rw title string
+--rw lang? string
+--rw authors* string
+--rw pub_year? year
+--rw price? uint64
YANG extension Statement
Sample YANG (stores.yang with extension) | Statements and Description |
---|
module stores {
…
prefix book-store;
…
extension sync-flag{
description
“This is a sample extension statement description“
argument "value";
}
container bookstore {
leaf bookstore-name {
type string;
}
….
}
module extended-stores {
yang-version 1.1;
...
import stores{
prefix book-store;
}
typedef year {
type uint16 {
range "1000..9999";
}
}
container bookstore {
book-store:sync-flag "on";
...
}
}
| extension Statement see example from Lines 5-9 on stores model with extension
extension <keyword/identifier>{
<extension substatements...>
}
see example from Line 15 on extended-stores model
<module prefix>:<extension keyword> "argument";
- to be used to define new statements
- available to be imported and used by other modules just like a normal YANG statement
- by use of 'import statement' to import the module where the extension is defined
- statements that do not have any substatements can have extensions defined if wanted
- its only one argument is the identifier and keyword for the extension
- Optional substatements:
- argument Statement
- description Statement
- reference Statement
- defined extension Statements
argument Statement see examples from Line 6 on stores model - takes a string argument which is the name of the argument to the keyword
- Optional substatement
|
<?xml version="1.0" encoding="UTF-8"?>
<module name="extended-stores"
xmlns="urn:ietf:params:xml:ns:yang:yin:1"
xmlns:ext-book-store="org:onap:ccsdk:sampleExtended"
xmlns:book-store="org:onap:ccsdk:sample">
<namespace uri="org:onap:ccsdk:sampleExtended"/>
<prefix value="ext-book-store"/>
<revision date="2020-09-15">
<description>
<text>Sample Extended Model</text>
</description>
</revision>
<import module="stores">
<prefix value="book-store"/>
</import>
<typedef name="year">
<type name="uint16">
<range value="1000..9999"/>
</type>
</typedef>
<container name="bookstore">
<book-store:sync-flag value="on"/>
<leaf name="bookstore-name">
<type name="string"/>
</leaf>
...
</container>
</module>
| yin-element Statement - takes a string argument which is true or false
- yin-element is 'false' by default
- if the argument is 'true' it indicates that the argument is mapped to an XML element in YIN or to an XML attribute
Notes - Line 22 on YIN-extended-stores model
- result of using the argument without specifying the yin-element value
- yin-element is 'false'
- the argument 'value' is only an XML attribute
- if argument statement (Line 6 on stores model) contains yin-element substatement YIN-extend-stores model would result to the following:
extension statement will produce a child node
...
<container name="bookstore">
<book-store:sync-flag>
<book-store:value>on</book-store:value>
</book-store:sync-flag>
...
</container>
...
|
** the YIN version and Schema trees above are generated by YANG validator 'pyang'
Existing YANG parser in CPS
(Please see https://wiki.onap.org/display/DW/Existing+Yang+Parser)
OpenDayLight Yang tools recognize YANG extensions
Test cases and scenarios
The following test cases used and modified the standard stores model seen above.
Key
**Green cell for case number indicates that groovy test in YangTextSchemaSourceSetSpec.groovy 'Building a valid YangTextSchemaSourceSet using #filenameCase filename) passes
**Red cell for case number indicates that tests have failed
Case # | Description | JAVA object | Notes |
1 | - extension defined as substatement in the module with argument statement as its substatement
- extension used inside container statement before all other substatements
- extension contained argument
module stores {
yang-version 1.1;
...
extension sync-flag{
description "This extension allows to tag nodes with a sync flag";
argument "value";
}
typedef year {...}
container bookstore {
book-store:sync-flag "on";
...
leaf bookstore-name {...}
list categories {..}
...
}
| | - extension declared after all other substatements of container still passed
|
2 | - extension defined as substatement in the module with argument statement as its substatement
- extension used inside a leaf statement (child of a container) before all other substatements
- extension contained argument
module stores {
yang-version 1.1;
...
extension sync-flag{
description "This extension allows to tag nodes with a sync flag";
argument "value";
}
typedef year {...}
container bookstore {
...
leaf bookstore-name {
book-store:sync-flag "on";
}
list categories {..}
...
}
| | - Extension declared after type-statement inside leaf statement (child of a container) still passed
|
3 | - extension defined as substatement in the module with argument statement as its substatement
- extension used inside list statement (child of a container) before all other substatements
- extension contained argument
module stores {
yang-version 1.1;
...
extension sync-flag{
description "This extension allows to tag nodes with a sync flag";
argument "value";
}
typedef year {...}
container bookstore {
...
leaf bookstore-name {...}
list categories {
book-store:sync-flag "on";
key "code";
...
}
...
}
| | - Extension declared after key-statement inside list statement (child of a container) still passed
|
4 | - extension defined as substatement in the module with argument statement as its substatement
- extension used inside leaf statement (child of list node from case #3) before all its substatements
- extension contained argument
module stores {
yang-version 1.1;
...
extension sync-flag{
description "This extension allows to tag nodes with a sync flag";
argument "value";
}
typedef year {...}
container bookstore {
leaf bookstore-name {...}
list categories {
key "code";
leaf code {
book-store:sync-flag "on";
type string;
}
leaf name {...}
list books {...}
...
}
| | - Extension declared after type-statement inside leaf statement (child of list node from case #3) still passed
|
5 | - extension defined as substatement in the module with argument statement as its substatement
- extension used inside list node (child of list node from case #4) before key-statement of list
- extension contained argument
module stores {
yang-version 1.1;
...
extension sync-flag{
description "This extension allows to tag nodes with a sync flag";
argument "value";
}
typedef year {...}
container bookstore {
leaf bookstore-name {...}
list categories {
key "code";
leaf code {...}
leaf name {...}
list books {
book-store:sync-flag "on";
...
}
...
}
| | - extension declared after key-statement of the list statement still passed
|
6 | - extension defined as substatement in the module with argument statement as its substatement
- extension used inside leaf-list node (child of list node from case #5) before all other substatements
- extension contained argument
module stores {
yang-version 1.1;
...
extension sync-flag{
description "This extension allows to tag nodes with a sync flag";
argument "value";
}
typedef year {...}
container bookstore {
leaf bookstore-name {...}
list categories {
key "code";
leaf code {...}
leaf name {...}
list books {
leaf-list authors{
book-store:sync-flag "on";
}
}
...
}
| | - extension declared after type-statement of leaf-list still passed
|
7 | - extension defined as substatement in the module with argument statement as its substatement
- extension used inside module
- extension declared before container node
- extension contained argument
module stores {
yang-version 1.1;
...
extension sync-flag{
description "This extension allows to tag nodes with a sync flag";
argument "value";
}
typedef year {...}
book-store:sync-flag "on";
container bookstore {...}
}
| | - data tree still only has one direct child (container node) as with the standard stores model
- value of the argument is not seen?
|
8 | - scenario the same as case 1 but the extension was used in the container statement without an argument
module stores {
yang-version 1.1;
...
extension sync-flag{
description "This extension allows to tag nodes with a sync flag";
argument "value";
}
typedef year {...}
container bookstore {
book-store:sync-flag;
...
}
| | - same extension declaration/usage fails for:
- scenarios in all cases 2-7
|