Table of Contents |
---|
Overview
The following study describes extending YANG language statements to allow customization of models.
References:
Jira Legacy server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key CPS-735 - https://datatracker.ietf.org/doc/rfc8526/
- https://www.rfc-editor.org/rfc/rfc6095.html
- https://www.hjp.at/doc/rfc/rfc6020.html#sec_6.3.1
- https://docs.opendaylight.org/en/latest/release-notes/upgrade-process.html?highlight=extension%20annotation#unrecognized-yang-statement-handling
- https://datatracker.ietf.org/doc/html/rfc6110#section-9.4
- https://datatracker.ietf.org/doc/html/rfc8791
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)..> } ;
- Statement syntax is either of the following :
- Modules contain a sequence of statements
* argument can be zero or one depending on the statement
* argument is a string
...
container nodes
...
Sample YANG
(stores.yang)
...
language | text |
---|---|
linenumbers | true |
...
Table of Contents |
---|
Overview
The following study describes extending YANG language statements to allow customization of models.
References:
Jira Legacy server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key CPS-735 - https://datatracker.ietf.org/doc/rfc8526/
- https://www.rfc-editor.org/rfc/rfc6095.html
- https://www.hjp.at/doc/rfc/rfc6020.html#sec_6.3.1
- https://docs.opendaylight.org/en/latest/release-notes/upgrade-process.html?highlight=extension%20annotation#unrecognized-yang-statement-handling
- https://datatracker.ietf.org/doc/html/rfc6110#section-9.4
- https://datatracker.ietf.org/doc/html/rfc8791
- Related JIRA stories:
Jira Legacy server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key CPS-866
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)..> } ;
- Statement syntax is either of the following :
- Modules contain a sequence of statements
* 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
- leaf nodes
- leaf-list nodes
- 4 types of nodes
Basic YANG statements
Sample YANG (stores.yang) | Statements and Description | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| module Statement see example from Line 1
see examples from Lines 2-16
typedef Statement see example from Line 12
container Statement see example from Line 18
leaf Statement see example from Line 27
list Statement see example from Line 35
leaf-list Statement see example from Line 41
|
Figure 1.1 Schema tree of module 'stores'
Code Block | ||||
---|---|---|---|---|
| ||||
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 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
The following model shows that it imported the model above where extensions is declared.
|
|
|
|
|
|
|
|
|
|
|
extension Statement see example from Lines 5-9 on stores model with extension
|
see example from Line |
- 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:
- 'key statement'
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'
Code Block | ||||
---|---|---|---|---|
| ||||
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
** the YIN version and Schema trees above are generated by YANG validator 'pyang'
Expected tree diagram for example-module based on RFC8340 (https://datatracker.ietf.org/doc/html/rfc8340):
Gliffy | ||||||||
---|---|---|---|---|---|---|---|---|
|
Existing YANG parser
(Please see https://wiki.onap.org/display/DW/Existing+Yang+Parser)
OpenDayLight Yang tools recognises YANG extensions
...
package org.opendaylight.yangtools.yang.model.api;
import org.opendaylight.yangtools.yang.model.api.stmt.ExtensionEffectiveStatement;
public interface ExtensionDefinition extends SchemaNode, EffectiveStatementEquivalent<ExtensionEffectiveStatement> {
String getArgument();
boolean isYinElement();
}
...
15 on extended-stores model
argument Statement see examples from Line 6 on stores model
| |||||||||||||||||||
| yin-element Statement
Notes
|
** the YIN version and Schema trees above are generated by YANG validator 'pyang'
Existing YANG parser in CPS
(Please see https://lf-onap.atlassian.net/wiki/display/DW/Existing+Yang+Parser)
OpenDayLight Yang tools recognize YANG extensions
Contains interface which has methods to access data of a YANG extension statement
Code Block language java theme Eclipse title Yang tools ExtensionDefinition Interface package org.opendaylight.yangtools.yang.model.api; import org.opendaylight.yangtools.yang.model.api.stmt.ExtensionEffectiveStatement; public interface ExtensionDefinition extends SchemaNode, EffectiveStatementEquivalent<ExtensionEffectiveStatement> { String getArgument(); boolean isYinElement(); }
Test cases and scenarios
The following test cases used and modified the standard stores model seen above.
Testing with groovy
The following cases were tested in YangTextSchemaSourceSetSpec.groovy using the test method 'Building a valid YangTextSchemaSourceSet using #filenameCase filename)'.
Key
**Green cell for case number indicates that tests have passed
**Red cell for case number indicates that tests have failed
- the extension is defined as substatement in the module with argument statement as its substatement
Case # | Description | JAVA object | Notes | |||||
1 |
|
| ||||||
2 |
|
| ||||||
3 |
|
| ||||||
4 |
|
| ||||||
5 |
|
| ||||||
6 |
|
| ||||||
7 |
|
| ||||||
8 |
|
| ||||||
9 |
|
| ||||||
10 |
|
Extra Notes:
- There seems to be no inheritance of the extension statement for the substatements wherein the extension was used
- The date tree and schema tree does not change sizes with the addition of the extensions for all cases shown above
Parsing a original data instance (json) using the extended model
Case # | Description | Result |
---|---|---|
1 |
|
|
2 |
|
*the same result acquired for all passed cases on the groovy tests table above |
3 |
|
|
4 |
|
|
Conclusions
- The YANG language extension analysis above is only applicable for seeing that it is good for type configuration.
- The extension does not extend the actual data of the model instance
- Based on the test scenarios above, extensions can only be seen on the schema sets and not on the data
- YANG extension can be used at every level of the tree model
- The test results show that the model is being recognized by the current YANG tools used to parse a model
- It fails for scenarios such as parsing a model without an argument defined when it is expecting it
- This analysis did not look further into the effect of setting yin-element to 'true' for the model instance
- Further investigation is required to cover interpretation as the analysis above only covers parsing
- see
Jira Legacy server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key CPS-866
- see