Is YANG Development Kit maintained? Should I look for alternatives?

hjensas — Tue, 22 Feb 2022 17:15:42 GMT

Hi,

What come below may come across as complaints, but my intent is constructive.

I've been experimenting with ydk-cpp and ydk-py from the YANG Development Kit.

I have tried to get it working on Fedora 35, CentOS 8 and Ubuntu, but I experience build issues and application crashes.

Based on documents and sample code it seems to be just what I need, if it would work on a non-Legacy platform. i.e CentOS 7 does not comply. (-:

The more I dig into the issues it becomes apparent that this is not maintained?

I find dependencies on retired projects, and build issues even on CentOS 8 stream.

Issues ydk-cpp:

Use of retired libnetconf
- The fork reference in CMakeLists does not compile on CentOS 8, due to changes in libssh. CESNET/libnetconf fixed this with https://github.com/CESNET/libnetconf/commit/159e155ffc0a98e2d74dcada0ea5868a5f7c59b9
- Switching to use libnetconf from https://github.com/CESNET/libnetconf instead of the fork
- But, looking at https://github.com/CESNET/libnetconf it states that this is no longer maintained
```
In 2016 we have moved our activity to libyang and libnetconf2.
The tools became mature in 2017 so the original libnetconf is
no more maintainedfrom that time.
```

On Ubuntu Focal the build fails on the ssh_threads, similar to the CentOS 8 issue. ssh_threads is no more, the symbols are in libssh since version 0.8.x afict.

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
ssh_threads_location
    linked by target "ydk" in directory /root/ydk-cpp/core/ydk

On Fedora 35 the libnetconfig fork referenced in ydk-cpp does compile, since Fedora ship a symlink:

# ls -l /usr/lib64/libssh_threads.so
lrwxrwxrwx. 1 root root 11 Sep 21 17:51 /usr/lib64/libssh_threads.so -> libssh.so.4

Issue ydk-py:

After compiling ydk-cpp core (libydk) and installing ydk-py (ydk-models-openconfig) from pypi I get seg-fault issues

Stack trace of thread 2535:
#0  0x00007f9c9af57591 method_dealloc (libpython3.10.so.1.0 + 0x127591)
#1  0x00007f9c9a3b4499 n/a (/home/rpmbuild/venv-ydk/lib/python3.10/site-packages/ydk_.so + 0x278499)

Debug log from my test application, I just get to doing NetconfServiceProvider() and then it crashes.

2022-02-22 16:28:49,869 - ydk - DEBUG - Trace: Publickey athentication
2022-02-22 16:28:49,869 - ydk - DEBUG - Trace: Trying to authenticate using pair /home/rpmbuild/ml2netconf /home/rpmbuild/ml2netconf.pub
2022-02-22 16:28:49,941 - ydk - DEBUG - Trace: Writing message (session 😞 
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:base:1.1</capability>
    <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
  </capabilities>
</hello>

2022-02-22 16:28:49,995 - ydk - DEBUG - Trace: Received message (session 😞 
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
        <capability>urn:ietf:params:netconf:base:1.0</capability>
        <capability>urn:ietf:params:netconf:base:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=report-all</capability>
        <capability>http://cisco.com/ns/yang/cisco-nx-os-device?revision=2021-12-14&amp;module=Cisco-NX-OS-device</capability>
    </capabilities>
    <session-id>877771875</session-id>
</hello>

2022-02-22 16:28:49,995 - ydk - DEBUG - NetconfSSHClient: NC session status: 1
2022-02-22 16:28:49,996 - ydk - INFO - Path where models are to be downloaded: /home/rpmbuild/.ydk/192.168.24.21
2022-02-22 16:28:49,996 - ydk - DEBUG - Creating libyang context in path: /home/rpmbuild/.ydk/192.168.24.21
2022-02-22 16:28:49,997 - ydk - DEBUG - [libyang] Extension plugin "/usr/local/lib/libyang/libyang_ext_test.so" successfully loaded.
2022-02-22 16:28:49,999 - ydk - DEBUG - [libyang] Extension plugin "/usr/local/lib/libyang/metadata.so" successfully loaded.
2022-02-22 16:28:50,001 - ydk - DEBUG - [libyang] Extension plugin "/usr/local/lib/libyang/nacm.so" successfully loaded.
2022-02-22 16:28:50,001 - ydk - DEBUG - [libyang] Reading module "ietf-yang-metadata".
2022-02-22 16:28:50,001 - ydk - DEBUG - [libyang] Module "ietf-yang-metadata@2016-08-05" successfully parsed as implemented.
2022-02-22 16:28:50,001 - ydk - DEBUG - [libyang] Reading module "yang".
2022-02-22 16:28:50,001 - ydk - DEBUG - [libyang] Resolving "yang" unresolved schema nodes and their constraints...
2022-02-22 16:28:50,002 - ydk - DEBUG - [libyang] All "yang" schema nodes and constraints resolved.
2022-02-22 16:28:50,002 - ydk - DEBUG - [libyang] Module "yang@2017-02-20" successfully parsed as implemented.
2022-02-22 16:28:50,002 - ydk - DEBUG - [libyang] Reading module "ietf-inet-types".
2022-02-22 16:28:50,002 - ydk - DEBUG - [libyang] Resolving derived type "union" failed, it will be attempted later.
2022-02-22 16:28:50,002 - ydk - DEBUG - [libyang] Resolving derived type "union" failed, it will be attempted later.
2022-02-22 16:28:50,003 - ydk - DEBUG - [libyang] Resolving derived type "union" failed, it will be attempted later.
2022-02-22 16:28:50,003 - ydk - DEBUG - [libyang] Resolving derived type "union" failed, it will be attempted later.
2022-02-22 16:28:50,003 - ydk - DEBUG - [libyang] Resolving "ietf-inet-types" unresolved schema nodes and their constraints...
2022-02-22 16:28:50,003 - ydk - DEBUG - [libyang] All "ietf-inet-types" schema nodes and constraints resolved.
2022-02-22 16:28:50,003 - ydk - DEBUG - [libyang] Module "ietf-inet-types@2013-07-15" successfully parsed as implemented.
2022-02-22 16:28:50,003 - ydk - DEBUG - [libyang] Reading module "ietf-yang-types".
2022-02-22 16:28:50,004 - ydk - DEBUG - [libyang] Module "ietf-yang-types@2013-07-15" successfully parsed as implemented.
2022-02-22 16:28:50,004 - ydk - DEBUG - [libyang] Reading module "ietf-datastores".
2022-02-22 16:28:50,004 - ydk - DEBUG - [libyang] Module "ietf-datastores@2017-08-17" successfully parsed as implemented.
2022-02-22 16:28:50,004 - ydk - DEBUG - [libyang] Reading module "ietf-yang-library".
2022-02-22 16:28:50,005 - ydk - DEBUG - [libyang] Module "ietf-yang-library@2017-08-17" successfully parsed as implemented.
2022-02-22 16:28:50,005 - ydk - DEBUG - Loading module 'ydk', revision '2016-02-26'
2022-02-22 16:28:50,005 - ydk - DEBUG - Getting module 'ydk' submodule 'none'
2022-02-22 16:28:50,005 - ydk - DEBUG - Looking for file in folder: /home/rpmbuild/.ydk/192.168.24.21
2022-02-22 16:28:50,005 - ydk - DEBUG - Opening file '/home/rpmbuild/.ydk/192.168.24.21/ydk@2016-02-26.yang'
2022-02-22 16:28:50,005 - ydk - DEBUG - Path found with revision: /home/rpmbuild/.ydk/192.168.24.21/ydk@2016-02-26.yang
2022-02-22 16:28:50,007 - ydk - DEBUG - [libyang] Module "ydk@2016-02-26" successfully parsed as implemented.
2022-02-22 16:28:50,007 - ydk - DEBUG - Loading module 'ietf-netconf', revision '2011-06-01'
2022-02-22 16:28:50,007 - ydk - DEBUG - Getting module 'ietf-netconf' submodule 'none'
2022-02-22 16:28:50,007 - ydk - DEBUG - Looking for file in folder: /home/rpmbuild/.ydk/192.168.24.21
2022-02-22 16:28:50,007 - ydk - DEBUG - Opening file '/home/rpmbuild/.ydk/192.168.24.21/ietf-netconf@2011-06-01.yang'
2022-02-22 16:28:50,007 - ydk - DEBUG - Path found with revision: /home/rpmbuild/.ydk/192.168.24.21/ietf-netconf@2011-06-01.yang
2022-02-22 16:28:50,008 - ydk - DEBUG - [libyang] Module "ietf-netconf@2011-06-01" successfully parsed as implemented.
2022-02-22 16:28:50,008 - ydk - DEBUG - Populating new module schema 'ietf-yang-metadata'
2022-02-22 16:28:50,008 - ydk - DEBUG - Populating new module schema 'yang'
2022-02-22 16:28:50,008 - ydk - DEBUG - Populating new module schema 'ietf-inet-types'
2022-02-22 16:28:50,008 - ydk - DEBUG - Populating new module schema 'ietf-yang-types'
2022-02-22 16:28:50,008 - ydk - DEBUG - Populating new module schema 'ietf-datastores'
2022-02-22 16:28:50,008 - ydk - DEBUG - Populating new module schema 'ietf-yang-library'
2022-02-22 16:28:50,008 - ydk - DEBUG - Populating new module schema 'ydk'
2022-02-22 16:28:50,009 - ydk - DEBUG - Populating new module schema 'ietf-netconf'
2022-02-22 16:28:50,009 - ydk - INFO - Connected to 192.168.24.21 on port 830 using SSH with timeout of -1
2022-02-22 16:28:50,012 - ydk - INFO - Disconnected from device
2022-02-22 16:28:50,013 - ydk - DEBUG - Trace: Writing message (session 877771875): 
<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <close-session/>
</rpc>

2022-02-22 16:28:50,110 - ydk - DEBUG - Trace: Received message (session 877771875): 
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
    <ok/>
</rpc-reply>

Segmentation fault (core dumped)

So, should I consider YANG Development Kit a non-candidate and move on?

If so are there any alternatives that can be recommended? (I did explore pyangbind, but it too seems non-maintained.)

It certainly feels like some maintenance is required, is there a community interest? If so I'm volontaring to help.

My wishlist:

Switch to libnetconf2
Use catch from the distribution (if the distribution ship it.)
Use spdlog from the distribution (if the distribution ship it.)
- Fedora ship it
- Ubuntu Focal ship it
Use libnetconf2 from the distribution (if the distribution ship it.)
- Fedora does ship it
Use libyang from the distribution (if the distribution ship it.)
- Ubuntu Focal does ship it
- Fedora does ship it
Provide packages in the distributions for libydk, just [apt-get|dnf] install libyang libyang-dev would make these tools much easier to consume, and as such broaden the user base.

Regards

Harald

Re: Is YANG Development Kit maintained? Should I look for alternatives

ygorelik — Tue, 22 Feb 2022 18:06:26 GMT

Hi Harald

The YDK language specific repositories (ydk-cpp, ydk-py, ydk-go) are holding old release (0.8.4) and not maintained anymore. Please move to YDK version 0.8.6, which supports newer platforms like Centos-8 and Ubuntu-20.

With regards to switching to libssh2 and libnetconf2. Unfortunately these are not in the current plans due to lack of resources.

Yan Gorelik

@cisco

Re: Is YANG Development Kit maintained? Should I look for alternatives

hjensas — Tue, 22 Feb 2022 18:31:18 GMT

Hi Yan,

Thank you for the quick reply!

I will check out ydk-gen repo, I notice the 0.8.6 version is only in your personal fork.

Will your commits be pulled into CiscoDevNet/ydk-gen at some point?

Harald

Re: Is YANG Development Kit maintained? Should I look for alternatives

ygorelik — Wed, 23 Feb 2022 00:35:09 GMT

At this point I do not have admin privileges over CiscoDevNet/ydk-gen repository. Therefore, please use my fork ygorelik/ydk-gen, which has latest, most updated YDK code and documentation.

Regards,
Yan

topic Is YANG Development Kit maintained? Should I look for alternatives? in Tools

Is YANG Development Kit maintained? Should I look for alternatives?

Re: Is YANG Development Kit maintained? Should I look for alternatives

Re: Is YANG Development Kit maintained? Should I look for alternatives

Re: Is YANG Development Kit maintained? Should I look for alternatives