[YANGTOOLS-837] Add support for varied model conformance Created: 22/Nov/17 Updated: 20/Jun/22 Resolved: 20/Jun/22 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | parser |
| Affects Version/s: | None |
| Fix Version/s: | 9.0.0 |
| Type: | Improvement | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
https://tools.ietf.org/html/rfc7895#page-9 and https://tools.ietf.org/html/rfc7950#section-5.6 defines a 'conformance' leaf to be associated with a module advertised by the device. There are two conformance levels:
We currently always 'implement' a module included in CrossStatementSourceReactor, even if it is only needed to satisfy imports (e.g. is added as libSource). For modules pulled in from the module library to satisfy imports we should mark the resulting effective module as import only and only process its reusable pieces (groupings, typedefs, identities). |
| Comments |
| Comment by Robert Varga [ 07/Mar/18 ] |
|
This information should be exposed via ModuleEffectiveStatement. Note that FeatureEffectiveStatementNamespace should only be exposing features that are supported, rather than all features present in the model. Each ModuleEffectiveStatement should also export the deviations which have been applied to the module. |
| Comment by Robert Varga [ 07/Mar/18 ] |
|
Preliminary patch: https://git.opendaylight.org/gerrit/69209 |
| Comment by Robert Varga [ 25/Mar/19 ] |
|
This requires modifications to the parser API, so that the implementation/import constraints are taken into account as as what deviations to apply, so that we do not automatically apply deviations and do not process instantiation statements. StatementDefinition needs to grow a new method, which will identify whether a statement defines a data definition node (and therefore should be ignored in the import-only case). |
| Comment by Peter Verthez [ 25/Nov/21 ] |
|
Is there an outlook on when this would be available? Having this would help us in reusing e.g. groupings from some YANG modules without actually marking support for those modules, for which we typically now copy those groupings over. |
| Comment by Robert Varga [ 29/Nov/21 ] |
|
I cannot commit to anything, as this keeps being pushed out by other priorities. A contribution or a contract would help landing this in a predictable timeline |