Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tree structure generated by CPS does not match the model #71

Open
kot-begemot-uk opened this issue Mar 9, 2018 · 3 comments
Open

Tree structure generated by CPS does not match the model #71

kot-begemot-uk opened this issue Mar 9, 2018 · 3 comments
Assignees

Comments

@kot-begemot-uk
Copy link

Dell-base-common augments ietf-interfaces.

The expectation would be that the keys should still be from ietf-interfaces instead of dell-base-common. Not the case.

Additionally, to add to the confusion, while the keys are under dell-base-cmn, the data is still under if/ +/- augmentations.

This makes the whole interface tree non-interoperable versus upstream implementations without remapping and re-parenting it for presentation.

@rakeshdatta
Copy link
Collaborator

@kot-begemot-uk Hi Anton, I am not sure about the problem yet.

Would be helpful, if you could please provide all the data as per the given guidelines:
https://github.com/open-switch/opx-docs/wiki/Report-bugs

@kot-begemot-uk
Copy link
Author

cps_get_oid.py if/interfaces/interface 'if/interfaces/interface/name=e101-001-0' should return EXACTLY what is presently being returned by cps_get_oid.py dell-base-if-cmn/if/interfaces/interface 'if/interfaces/interface/name=e101-001-0'
Instead it returns nothing.
This violates the concept of augmentation as described in RFC6020, RFC7950 (yang) and is incompatible with well established representations of RFC8040 (restconf) and 6241 (netconf)

@kot-begemot-uk
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants