[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 |
||
| Issue Links: |
|
||||||||
| 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. 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. |