How to inject config false data into data tree during data parsing

[steweg]

Hi,

I was asked to provide some sort of solution in my project for the following use-case. Here is a minimal data model to illustrate:

module a {
    yang-version "1.1";
    namespace "something:a";
    prefix a;

    leaf attr1 {
        type enumeration {
            enum "val1";
            enum "val2";
        }
        mandatory true;
    }

    leaf-list attr1-suboptions {
        type string;
        //calculated based on "attr1" value
        config false;
    }

    leaf-list selected-suboptions {
        type string;
        //if leaf-list will not be "config false", it would really be "type leafref {path "../attr1-suboptions";}
        min-elements 1;
        custom-ext:path "../attr1-suboptions"; //this converts it into fake leafref with given path
    }
}

Based on the above we have web form created. Depending on value of attr1, our system should calculate and inject possible values of suboptions based on certain business logic, which is quite complex as in reality it doesn't just depends on attr1, but many other attributes (so changing the YANG model in some way is not really an option). Once the options are calculated, they are injected in UI to read-only field and injected into data tree using lyd_new_term() API. And user should then be able to fill in the selected-suboptions, be. Having all the data available, then I should store the final JSON value like this:

{
 "a:attr1": "val1",
 "a:selected-suboptions": ["sub1", "sub2"]
}

so far everything is ok. But now let's try to load the JSON (e.g. user would like to perform some modifications).

When I load the JSON, using lys_parse() API, it is ok in regular YANG, but because of the extension, I am getting error as "attr1-suboptions" was not yet added into the data tree.

So my question is how can I inject "config false;" data nodes into the tree during parsing of JSON data? Is this even possible? Or libyang supports only "parsing the input data" and only then add "config false" data nodes?

Thanks

[michalvasko]

So my question is how can I inject "config false;" data nodes into the tree during parsing of JSON data? Is this even possible?

No, you cannot do anything like this but why don't you first get the state data, append them to the config data and then you can validate them all together.

[steweg]

I tried to do that, but when I added into JSON state data, which supposed to be config false, I was getting error during parsing as follows (using lys_parse() API):

Unexpected data state node "attr1-suboptions" found.: Data path: /a:attr1-suboptions (line 3)

So maybe I am doing something wrong or I misunderstood your proposal...

[michalvasko]

No, you just need to use the correct flags and we are talking about lyd_parse_*() functions (not lys_parse()). Obviously, you need to drop LYD_PARSE_NO_STATE if you want to validate state data, I expect you were using it if you got this error.

[jktjkt]

I do not fully understand the question; in particular, when the input data refer to an extension, you really only have two options:

• either you completely ignore that extension and anything which references the extension data,
• or you load the extension implementation into your YANG validator (so, in this case, into the libyang context) and let it perform whatever this non-standard implementation has to perform.

But maybe your extension is loaded and activated, and perhaps your extension implementation treats custom-ext:path as if it was a magic leafref that's actually allowed to refer to state data? In that case, the extension was obviously designed to only work with a combination of config + state data, so it's clearly an undefined operation to try to "activate" this extension on a data set which only contains config data and no state data.

As you state, it is not possible to validate config data against state data; that's a design decision in the YANG standard. What you might try to do is adding a bunch of integrity checks to your state data to reference the config data; the downside is that the data paths which are reported as failing validation will lead to your state data and not to the config. Then, when it comes to validation, the NMDA starts to matter, and the operational DS (which is the only one with state data allowed) is defined as a datatore which might have some content that does not pass validation.

In our internal use case where we have some devices with different, say, number of ports, we've introduced YANG-level features. That way we can do, say, an if-feature hw-port-20, and enforce some conditional constraints based on that, and a different set of constraints for if-feature hw-port-8. This might or might not work for your use case, and it's definitely not a dynamic mechanism. We're using that in a scenario where the limitation is known at the device's manufacturing time, and it will only support a relatively smart number of possible "HW variants".

[steweg]

@michalvasko @jktjkt: Thank you both for suggestions.

It turned out that my primary issue was actually something totally different. It is related to bug which was fixed in #2230