References
- Relevant user story - CPS-1153Getting issue details... STATUS
- IETF documentation on extending data models
- Augment statement
- (YANG language summary) Support for Yang Language
Overview
Currently, the published DMI-registry model shows the property 'additional properties' as shown on lines 32 to line 43 of the yang model below. This property is not queryable and therefore, is not recommended to be published to the public.
The purpose of this study is
- to propose an alternative model so there will be 2 yang models wherein one depends on the other.
- One is public and seen on CPS-E05 then augments to what is visible to the NCMP-DMI implementations
module dmi-registry { yang-version 1.1; namespace "org:onap:cps:ncmp"; prefix dmi-reg; organization "Nordix Foundation"; contact "rahul.tyagi@est.tech"; revision "2021-05-20" { description "Initial Version"; } container dmi-registry { list cm-handles { key "id"; leaf id { type string; } leaf dmi-service-name { type string; } list additional-properties { key "name"; leaf name { type string; } leaf value { type string; } } } } }
Extending data models (augment)
See brief on YANG language on Support for Yang Language
By using the keyword 'augment' on yang models, we are allowed to extend a data model i.e. add nodes to the current structure
The argument following this keyword is the location in the data model hierarchy to the extension is to be added.
For example, if we want to add a new list directly inside the list 'cm-handles' in the 'dmi-registry' container of the current dmi-registry model then the argument for the augment keyword would be /dmi-registry/cm-handles
- where augment statements can add nodes
- container
- list
- choice
- case
- input
- output
- notification node
The following models are proposed to achieve augmentation:
1. Dmi Registry model without the 'additional properties'
module dmi-registry { yang-version 1.1; namespace "org:onap:cps:ncmp"; prefix dmi-reg; organization "Nordix Foundation"; contact "rahul.tyagi@est.tech"; revision "2021-05-20" { description "Initial Version"; } container dmi-registry { list cm-handles { key "id"; leaf id { type string; } leaf dmi-service-name { type string; } } } }
2. Model that holds the 'augment' statement
module sampleDmiAugment { yang-version 1.1; namespace "org:onap:cps:ncmp/private-dmi-model"; prefix dmi-aug; import dmi-registry { prefix "dmi-reg"; } augment "/dmi-reg:dmi-registry/dmi-reg:cm-handles" { description "Private additional properties"; list additional-properties { key "name"; leaf name { type string; } leaf value { type string; } } } }
Using pyang tool, these two models were validated to confirm that the resulting schema tree module model includes the nodes that were intended to be added to the dmi-registry model
Testing
Successful Parsing of the models [dmi-registry-sample, extended-dmi-registry]
Description | Notes and Results | ||
---|---|---|---|
1 | Create Dataspace | dataspace 'my-dataspace' created |
|
2 | Create schemaset with Zip File resource
| 201 created 'my-schema-set-2' |
|
3 | Create Anchor
| 201 created 'my-anchor' |
|
4 | Create Node
| 201 created | |
5 | Get a schemaset
| 200 |
Open Issues/Questions
Issue/Question | Description | Notes | Resolution |
---|---|---|---|
new model |
| new module name = extended-dmi-registry prefix = ext-dmi | |
Loading data with Liquibase | Dmi registry model is loaded via Liquibase which means that the content of the yang resource is already set
| ||
ODL Yang tool | what is needed to acknowledge the augment statement for a new model
|
|