Gaps in Yang tree

[kot-begemot-uk]

It is a standard expectation for a yang tree that a read at any level will yield the branches under that level.

For example:

if we have a tree of {"if":{"interfaces":[...]}} a read at if will produce the contents of the "if" container and all of its included lists.

In cps it does not - there are several places in the model where the top level container containing interesting lists cannot be read. Specifically - the above example (it is parented in the incorrect location - dell-base-cmn which is in a separate issue).

[rakeshdatta]

@kot-begemot-uk Hi Anton, I understand your concern.
For me to be able to present the case better, can you please help me with the information asked in https://github.com/open-switch/opx-docs/wiki/Report-bugs

[kot-begemot-uk]

cps_get_oid.py if/interfaces should produce result.

Specifically, it should return the enveloping container and the full list should be presently obtainable under cps_get_oid.py if/interfaces/interface

Due to CPS yang-data data bug #71 that is presently erroneously returned at cps_get_oid.py dell-base-if-cmn/if/interfaces

That does not, however change the overall issue - it should be possible to request the tree at any level and the implementation should recurse down to grab all underlying elements same way all other yang implementations do.

[kot-begemot-uk]

What is the problem you are reporting - Fundamental design fault
Do you have a use case including examples? - yes, stated
Is there a blocker? (Y/N), and include the reasoning if it is a blocker. - it is a blocker for implementing restconf, netconf or any other interop natively without presenting a "hacked" model to the consumer
OPX version that you are using (latest or specific version) - all up to head of tree
Which platform are you using? - Irrelevant as bug is on all platforms
How frequently is the bug reproducible (always, intermittently, and so on)? - Always
Include the steps to reproduce the problem - Just read the rfc please
Include any logs (journalctl -f, opx-show-version, opx-show-system-status, and so on). - not applicable
Have you found a workaround that resolves your problem? - none