sysrepo
sysrepo copied to clipboard
sysrepo
taxonomy of sysrepo CLI-ish
If I may alllow, I did notice the followings:
- klish - https://github.com/nawawi/klish by @nawawi and @pkun
- netconf-cli: https://github.com/CESNET/netconf-cli by @syyyr and @jktjkt
- onm-cli : https://github.com/okda-networks/onm-cli by @ali-aqrabawi
- clixon: https://github.com/clicon/clixon by @olofhagsand
- +maybe some few others ?
doesn't it mean that sysrepo deserves a CLI ? or should everyone build its own one ?
So what are you saying, that there should be at least a 3rd sysrepo CLI (in addition to netconf-cli and onm-cli) considered "official" directly in the repository? I really do not see the point, we only provide sysrepoctl and sysrepocfg that allow working with sysrepo in shell. Perhaps these 2 projects can be linked in sysrepo README but I am not sure what else do you expect.
The netconf-cli project also provides sysrepo-cli which directly interfaces with sysrepo. Netconf-cli/sysrepo-cli strives to be a generic interface, so it ideally, it shouldn't be needed to write your own cli. Although, for your purposes, it might be beneficial to write something more specific. It depends on how you want to interact with sysrepo.
Possibly the problem is having too many CLIs being built, sysrepo being a data store needs a CLI that can be used for production not just testing as in the case for sysrepocfg, similar to netopeer being the go to netconf server for sysrepo, maybe its good to focus the community towards one CLI project.
the reason behind the cli is to easily edit and configure sysrepo yang data, it's really challenging to do it with sysrepocfg specially if the user is not well versed with the models he is working with,
i think it would be great to have the 2 projects mentioned in sysrepo README. so users will have the option.
Try the sysrepo version of netconf-cli - sysrepo-cli, it seems that that is what you'll looking for. If it doesn't suit your needs, you can always create an issue and/or contribute to the project.
will give it a try for sure, but the idea is to have these projects visible to sysrepo users, if i searched google for "sysrepo cli", i won't see netconf-cli nor onm-cli in the search result, so i will start thinking of building my own cli :D,
I think there is no problem at all. Sysrepo has own native netconf-cli. If you want "official" cli then use it. I don't use it because I need another way to interact with user - without XPath knowledge. Additionally I need non-RPC commands for "enable" mode. So I have written klish. It's not a problem of "better" or "worse" CLI. The question is which look-and-feel do you want and how to embed this CLI to target system. Someone needs one and someone needs another. The single unified CLI will no be suitable for everyone.
May be it's a question to documentation but it's only Sysrepo authors decision to add or not the links to third party projects.
As far as I know clixon has its own internal storage but not Sysrepo isn't it?
Since it can become a wide and complexe task to cover all Linux "networking" ; I feel that we need to federate "one" CLI. Maybe it would mean 1 single look&feel.
If I recall correctly, when we started working on netconf-cli/sysrepo-cli/yang-cli back in 2018, there were no generic clients that would fetch the YANG modules and build the UI based on the "shape" of these YANG models. In fact, I remember that having to hand-craft an XML for sysrepocfg was one of the moments which led to yang-cli :). During these six years the project grew, and it's now running as a local shell on our ROADMs.
The UX is not that great for people who are not familiar with YANG, even though the tab-completion hopefully goes a long way towards making it manageable. One thing which is really limiting is the sort-of-amalgamation of the operational and running datastores (CESNET/netconf-cli#16, CESNET/netconf-cli#15). I think that the CLI will in future differentiate between "reading mode" and "edit mode" (a.k.a. conf t). It's good to see that other CLIs made a better decision right at the very beginning.
As of the choice of XPaths and making them rather prominently visible in the UI, we are not that strongly attached to these, either. It's simply the fact that we wanted to avoid designing our own DSL. Saying interface eth0 is straightforward for sure, but YANG has lists with N keys, there are keyless lists in operational data, etc. All of that could be solved, but "just using XPath" felt like the easiest thing, and we made sure that when people keep hitting the <Tab> key, they will usually end up with a command that does the Right Thing™.
And perhaps most importantly: our CLI is an open source project, and we're happy to accept patches as well as to hear feedback and receive proposals which improve the UX. About the only "hard rule" is that the CLI is supposed to work with YANG data, and to implement whatever is needed to explore, read, modify, etc. the content of a "YANG database" -- be it a local sysrepo datastore, a remote NETCONF server, an in-memory YANG snapshot, or (in future) a RESTCONF server. Patches welcome.
I think there is no problem at all. Sysrepo has own native netconf-cli. If you want "official" cli then use it. I don't use it because I need another way to interact with user - without XPath knowledge. Additionally I need non-RPC commands for "enable" mode. So I have written klish.
I glanced at the homepage, but I did not find any English docs about the project or the part that's related to sysrepo. Just my two cents here, but I think it would be great to have English docs.
Perhaps these 2 projects can be linked in sysrepo README but I am not sure what else do you expect.
Yes; I've always felt that https://www.sysrepo.org/plugins is buried too deep -- especially when there's the "Ecosystem" link at the top of sysrepo.org which only mentions libyang/sysrepo/libnetconf2/netopeer2.
Okay, I have added links to some sysrepo CLI implementations, netconf-cli and onm-cli seem fine. But klish, without EN docs, would not be usable for most users, so I can add it once you improve that @pkun. And I have also not found any indication that clixon would be connected to sysrepo so that does not seem relevant.