[YANGTOOLS-740] Support for a mode where the if-feature information is exposed in the created SchemaContext Created: 01/Feb/17  Updated: 10/Apr/22  Resolved: 18/Sep/17

Status: Resolved
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Peter Verthez Assignee: Peter Kajsa
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Blocks
blocks YANGTOOLS-381 Yang parser and Yang model API should... Resolved
External issue ID: 7721

 Description   

Currently, from the Boron release onwards, the YANG parser allows to provide a list of features that are supported, and it will transparently remove the unsupported nodes from the resulting SchemaContext.

This implies that you end up with a separate model for each device that is connecting (well, with sharing of similar models), but it also means that you can only know the correct model once the device has connected, because only then the supported features are known.

In a case of pre-provisioning you would like to have the correct model upfront. The idea is then that at the moment that you push that to the device, you remove all the nodes that are not supported in that specific device based on the if-feature information. However, with the current YANG parser support this is not possible, or you would have to make models with all possible combinations of features. We can create a model that contains all features (by saying that all features are supported), but the model then does not give information that some nodes are feature-dependent.

So we request that a separate mode is introduced where you don't provide the features in advance, and the SchemaContext then contains feature information per SchemaNode.



 Comments   
Comment by Robert Varga [ 14/Feb/17 ]

Nitrogen planning has not started. This also has no place in effective model of the world, maybe in the declared one – in some shape or form.

Comment by Peter Kajsa [ 09/Aug/17 ]

Hmm.. then one possible option now is to process Module as EffectiveStatement and access to it via org.opendaylight.yangtools.yang.model.api.stmt, where if-feature statements are accessible.

e.g.
((EffectiveStatement<?, ?>) module).getDeclared()
...

But I am not sure, whether this is sufficient for you.. ?

Comment by Peter Verthez [ 16/Aug/17 ]

I'm not sure what that would mean then. What does this getDeclared() return? Are those again SchemaNodes?

If it is something else and SchemaNode would not have the if-feature info, this would mean that all our schema handling which uses SchemaNode would have to be duplicated for that other class, which doesn't seem to be useful.

Comment by Robert Varga [ 16/Aug/17 ]

SchemaNode is the effective model of the world. If a SchemaNode object additionally implements EffectiveStatement, getDeclared() allows to cross over to underlying declared model (if applicable).

Comment by Robert Varga [ 18/Sep/17 ]

As far as I understand, this information is already available via yang.model.api.meta interfaces.

Comment by Peter Verthez [ 18/Sep/17 ]

OK for me, we'll try your proposal.

Generated at Wed Feb 07 20:54:10 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.