Table of contents:
Addresses: CPS-287 - Getting issue details... STATUS
YANG Schema Mount Mechanism Overview
The YANG schema mount mechanism is described in RFC-8528.
In opposite to standard YANG's "use" and "augment" the schema mount mechanism allows the model modification at runtime.
While parent (extendable) module require to define the mount point(s) any already defined (legacy) module (including standard)
can be used as a mounted model.
The ietf-yang-schema-mount module defined in RFC-8528 defines structures for following entities:
- mount-point - for mount point(s) definition within parent (extendable) module
- schema-mounts - describes the model for actual assignment of mounted models to mount points
mount-point
Mount point is uniquely identified by its name (label) and the only requirements are
- allocation only within a YANG module of version 1.1+
- allocation only within a "
container" or a "list" definition
Below is example of simple mount-point definition
module test-mount {
yang-version 1.1;
namespace "org:onap:cps:test-mount";
prefix tmount;
revision "2020-02-02";
import ietf-yang-schema-mount {
prefix yangmnt;
}
container root-element {
yangmnt:mount-point "root-mp";
}
}
schema-mounts
While mount-point is a part of YANG definition the schema-mounts definition is delivered as data and it's expected
the server is capable to recognize this data as a model configuration update (modification).
The schema-mounts data describes which module to be attached to which mount-point (uniquely identified by
extended module name and mount point label). The reference to mount point is (expected to be) unique combination
of module name and a label assigned to mount point. The reference to mounted model could be various (described below).
Below is example of schema-mount data set referencing model to be taken from a library:
{
"ietf-yang-schema-mount:schema-mounts": {
"mount-point": [{
"module": "test-mount",
"label": "root-mp",
"shared-schema": {}
}]
}
}
Mounted model can be addressed the one of the following ways:
Known library item
Using shared-schema empty body (as in example above) indicates the model will be referenced by data while
it's expected (assumed) the model definition (YANG) to be taken from a server library identified earlier.
So if the data looks like below (addresses test-mount module described above):
{
"test-mount:root-element": {
"root-mp": { // mount point
"mounted-module:mounted-container": { // mounted module reference
// data associated to mounted module
}
}
}
}
it assumes there is a module with name "mounted-module" (known by the server) having root level container
named "mounted-container".
In order to address a mounted module as belonging to shared "shared-schema" the server needs a configuration
instruction as described RFC-8525, the yang-library message to be like below
{
"ietf-yang-library:yang-library": {
"content-id": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899",
"module-set": [
{
"name": "module-set",
"module": [
{
"name": "mounted-module",
"revision": "2020-02-02",
"namespace": "urn:org:onap:cps:test:mounted-module"
}
// other modules
]
}
]
}
}