Re: Klish 3 & Sysrepo

[Serj Kalichev]

Hi!

There is documentation for the klish-plugin-sysrepo that makes klish to work with sysrepo.

https://src.libcode.org/pkun/klish-plugin-sysrepo/src/master/docs/klish-plugin-sysrepo.en.md

The plugin has examples that use PLUGIN tag to attach C-written binary plugin with sysrepo-related functions (symbols).

Probably you found an XML with "del", "set" etc. XML COMMANDs from plugin source code. Just put this XML to your XML dir.

Generally it's enough. Go to "configure" mode and do "set", "del", "commit". And "show" command probably works (deals with sysrepo data store). It automatically use YANG-defined config tree.

Please, write to the kl...@googlegroups.com. May be someone has the same questions.

 

16.06.2025 18:33, Aleksander Djuric пишет:

Hi Serj!

I've installed klish 3 and Sysrepo on my Linux VM, but I can't find any documentation on how to configure Klish to work with Sysrepo. Can you have any examples to see how it should work?
For example, how to configure Klish to make a simple command like `show interface eth1` work using Sysrepo?

Many thanks in advance!

In the klish 3 following commands are now available:

  check   Verify the candidate configuration
  commit  Commit data to running-config
  del     Delete data from configuration
  diff    Show diff relative running-config
  do      Execute operational mode command
  edit    Change hierarchy level
  exit    Exit configuration mode
  insert  Insert statement to specified position
  quit    Quit to the main menu
  reset   Reset to running-config
  set     Set data to configuration
  show    Show data hierarchy
  top     Change hierarchy level to the top one
  up      Up hierarchy level

Here is the list of installed modules in Sysrepo:
# sysrepoctl -l
Sysrepo repository: /etc/sysrepo

Module Name                | Revision   | Flags | Startup Owner | Startup Perms | Running Perms | Submodules | Features                
----------------------------------------------------------------------------------------------------------------------------------------
ietf-datastores            | 2018-02-14 | I     | root:root     | 444           | 444           |            |                          
ietf-factory-default       | 2020-08-31 | I     | root:root     | 600           | 600           |            | factory-default-datastore
ietf-inet-types            | 2013-07-15 | i     |               |               |               |            |                          
ietf-netconf               | 2013-09-29 | I     | root:root     | 644           | 644           |            |                          
ietf-netconf-acm           | 2018-02-14 | I     | root:root     | 600           | 600           |            |                          
ietf-netconf-notifications | 2012-02-06 | I     | root:root     | 644           | 644           |            |                          
ietf-netconf-with-defaults | 2011-06-01 | I     | root:root     | 444           | 444           |            |                          
ietf-origin                | 2018-02-14 | I     | root:root     | 444           | 444           |            |                          
ietf-yang-library          | 2019-01-04 | I     | root:root     | 644           | 644           |            |                          
ietf-yang-metadata         | 2016-08-05 | i     |               |               |               |            |                          
ietf-yang-schema-mount     | 2019-01-14 | I     | root:root     | 644           | 644           |            |                          
ietf-yang-structure-ext    | 2020-06-17 | i     |               |               |               |            |                          
ietf-yang-types            | 2013-07-15 | i     |               |               |               |            |                          
sysrepo-factory-default    | 2023-02-23 | I     | root:root     | 600           | 600           |            |                          
sysrepo-monitoring         | 2023-08-11 | I     | root:root     | 600           | 600           |            |                          
sysrepo-plugind            | 2022-08-26 | I     | root:root     | 644           | 644           |            |                          
yang                       | 2022-06-16 | I     | root:root     | 444           | 444           |            |                          

[Aleksander Djuric]

Hi! Thanks for you help!

I read the above documents but could not find a working example of the Yang model with the ability to perform any actions.
For example, how can I configure Klish to get working commands for viewing running, candidate and startup configuration?
How can I manipulate these configurations?
I have many Yang models installed into Sysrepo, but the "show" command from the configuration example only shows nothing.

One more question - is here any way to autocomplete string variables like the network interface names in the 'set' command?

Sorry if I missed something in the documentation.

понедельник, 16 июня 2025 г. в 20:45:40 UTC+3, Serj Kalichev:

[Serj Kalichev]

Hi

Probably you need to read about YANG and sysrepo principles.

The YANG is just a language to define config-scheme. It doesn't do any actions itself. The sysrepo is just a store for configs that correspond to YANG-scheme. The sysrepo can store two main configs - running-config and candidate config.

It's a really complex theme - the difference between CISCO-like configuration and Juniper-like (YANG, sysrepo) configuration. I have an unfinished paper about it but paper is actually unfinished and I have no enough time now to finish and translate it. The main difference is the CISCO applies changes immediately when the user changes config but Juniper changes "candidate" config and don't apply it. It will be applied when user calls "commit" command. It copies candidate-config to running-config. The sysrepo has a mechanism to notify special listening services that running-config is changed so these services will actually apply new configuration.

You can use klish-plugin-sysrepo/xml/sysrepo.xml in your project. So what do you get exactly? Now you can call "configure" command so you get into configure-mode. Here you can modify candidate-config as you want. When you call "commit" the the candidate-config will be copied to running-config and sysrepo can notify subscribed services (if you have them) about config changes. If you call "show" within configure-mode you will see the current candidate-config. If you call "show running" from command-mode or "do show running" from configure-mode you will see current running config.

You don't see anything because you has no configuration at all. It's empty. The sysrepo shows loaded YANG modules. I.e. config scheme but not config itself. Modify your configuration first by the "set" command and then you can see your candidate and running configs.

The klish-plugin-sysrepo contain additional YANG file in yang/klish.yang that extends YANG scheme. It has "completion" extension to generate autocompletion from another parts of config by Xpath expression. The interfaces must be defined within configuration to be used as a completion. But I'm not ready to write example right now because it was implemented more than year ago. Later...

--
You received this message because you are subscribed to the Google Groups "klish" group.
To unsubscribe from this group and stop receiving emails from it, send an email to klish+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/klish/59220412-1d0b-4d2c-bf32-7bdbdcdf78can%40googlegroups.com.