I have two yang models with same root node but different namespaces though.
From CLI, the root nodes are shown with namespace prefix(for eg in configure mode - set first:container1, set second:container1) for conflicting ones and child nodes are shown without namespaces as the tree is different.
I would like to hide “first:container1” node in CLI and have “second:container1” available without namespace prefix like “container1” in CLI. For NETCONF NBI and internal purposes, I still want to keep schema with “first:container” in CDB.
Could you please let me know whether it is possible and how can handle this scenario.
you have multiple possible options, depending on usability/use-case needs…
If you don’t need to change the visibility during runtime, and it’s ok to hide whole module - most simple approach should be to export the YANG model or its part only for some specific APIs, excluding cli. During build process, when creating FXS files from YANGs, you can either:
use a flag “confdc --export agent”
(see user guide or man confdc).
or annotate module with “tailf:export agent” annotations
(details in UG or man tailf_yang_annotations)
thanks for your response.
How can we do it runtime and nacm based if possible?
Another way to compare the scenario is with ncs devices model. It already got “devices” container and used internally by NCS/NSO I believe. There is standards model with different namespace has “devices” container as well. So, can we hide “ncs:devices” for all CLI users and expose “devices” from standards model without namespace prefix? At the same time, make ncs:devices visible for special CLI user to be able to retrieve/debug NCS/NSO perspective of internal device model.
for runtime visibility limitation, you could use either tailf:hidden annotation to put specific nods into hide-group, or possibly the NACM like you mention.
I haven’t played much with multi-namespace scenarios, so i cannot say currently if the NACM deny rule for one of same-named subtrees will take care of removing the namespace prefix - you can try and experiment with your specific sub-models…
Same for me & NCS/NSO, not much complex experience - the devices nodes in NCS/NSO are rather special and major part of orchestrator architecture, so i am not sure if it can be overloaded/hidden. In addition, there should be no conflicts, as device models containing the “devices” root node are not mounted together with NSO/NCS models on device, thus there should be no issue/namespace conflict?