yang-data and restconf

[choppsv1]

I'm working on a RESTCONF server. One of the things to implement is returning the operations (RPCs) supported on the server. The operations supported are obtained by a RESTCONF client by doing a GET on /restconf/operations; however, the return value is modeled using the yang-data extension defined in the ietf-restconf module. I see there is a plugin in libyang for yang-data, but if I understand the tests that are testing this plugin, the only thing being tested is that libyang can parse YANG modules that include the use of this extension. I don't see any creation of data nodes corresponding to yang-data modeled data.

Is it possible to use libyang to create an actual tree of data nodes corresponding to the yang-data defined in ietf-restconf?

[michalvasko]

You are right, I could not find tests for this, which seems weird. In any case, it should work normally but you will have to use lyd_new_ext_*() to create the top-level node. Once you have the parent, you should be able to use all the standard functions. As for parsing, there is lyd_parse_ext_data().

[jktjkt]

Just in case you didn't know, we have a pretty usable RESTCONF implementation on top of sysrepo. What you see in the master branch is a bit old (libyang-v2 with a lot of missing features), but we do have stuff for libyang-v3 in our Gerrit; see the current tip at GitHub. It's not a complete RESTCONF implementation just yet, but we're getting there.

Now, I understand you don't use sysrepo, but maybe some of the trickier libyang bits that we do might still help you. I remember we ended up reporting and fixing some libyang bugs over the past few months. We do not currently implement the "API resource", so there's no RPC listing (and BTW, that only does RPCs, not actions, right?). However, from YANG perspective it seems similar to how errors are treated, and that was very easy to code.

For a few more examples on RESTCONF-specific parsing, you might also see the unit tests in libyang-cpp.

[choppsv1]

Thanks for the code/pointers. Unfortunately I wasn't able to figure out how to get to the SHA you pointed at in github using git. I do see a lot of interesting stuff in that gerrit link too, but also not sure how to access that with git either. :)

[jktjkt]

Oops, sorry, yeah, that's the cost of our workflow with Gerrit and linking to GitHub. Here's how you can get these:

• start with a clone
• git ls-remote origin | grep c4a6eaf95cccd6ea12419006837668b81ae5f850, which says c4a6eaf95cccd6ea12419006837668b81ae5f850 refs/changes/38/7338/1
• that refs/changes/X/Y/Z is the ref name that can be used for fetching, such as:
  • git fetch origin refs/changes/38/7338/1
  • git checkout -b some-local-name
  • git reset --hard FETCH_HEAD

Or go to the list of unmerged changes for rousette, pick the most recent one, and use the download links that are shown at the right side of the screen. You should be able to fetch via HTTPS with no login. Gitiwise, it's the same repo, also with complete history, and as a bonus you got clickable links to these funny ref names (which are "each version of each patch ever uplaoded", which is why they are so funny).

[jktjkt]

Another tip that we use for command-line usage is this for each of our repos:

[remote "origin"]
        url = ...
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = refs/notes/review:refs/notes/review
        fetch = refs/changes/*:refs/changes/*

and this one globally:

[alias]
    lola = log --graph --decorate --pretty=oneline --abbrev-commit --branches --tags --remotes HEAD --exclude refs/changes/*/meta --exclude refs/meta/dashboards/* --exclude refs/notes/review --decorate-refs=HEAD --decorate-refs=refs/*

...which gets you the following via git lola --all:

You can then go back to Gerrit's review page for each patch via git log --notes=review.

(End of the unsolicited Gerrit advert now.)