Add suppor for "when" statements

[lgifre]

Hi Rob!
How are you doing?

I found a bug (or I'm doing something wrong) when using the "when" statement.
I'm using: pyang (1.7.1) and pyangbind (0.5.10)

Assume you have the next simple model, where a field/set-of-fields are enabled only when an object is of a specific kind:

module model {
	namespace "urn:yang:model";
	prefix m;

	identity Kind;
	identity Kind-A { base "Kind"; }
	identity Kind-B { base "Kind"; }

	container con {
		leaf kind { type identityref { base Kind; } }
		
		choice fields {
			case fields-a {
				when "../../kind = 'Kind-A'";
				leaf fieldA { type uint32; }
			}
			case fields-b {
				when "../../kind = 'Kind-B'";
				leaf fieldB { type uint32; }
			}
		}
	}
}

I generate the model using the following command...

export PYBINDPLUGIN=`/usr/bin/env python -c 'import pyangbind; import os; print "%s/plugin" % os.path.dirname(pyangbind.__file__)'`
pyang --plugindir $PYBINDPLUGIN -f pybind --use-xpathhelper --split-class-dir model model.yang

And then I run the next python code...

from model.con import con
from pyangbind.lib.pybindJSON import dumps

cND = con()
cND.fieldA = 1
cND.fieldB = 2
print 'kind=Not Defined =>', dumps(cND, mode='ietf'), '\n'

cA = con()
cA.kind = 'Kind-A'
cA.fieldA = 3
cA.fieldB = 4
print 'kind=Kind-A =>', dumps(cA, mode='ietf'), '\n'

cB = con()
cB.kind = 'Kind-B'
cB.fieldA = 5
cB.fieldB = 6
print 'kind=Kind-B =>', dumps(cB, mode='ietf'), '\n'

And the output is...

kind=Not Defined => {
    "model:fieldB": 2, 
    "model:fieldA": 1
} 

kind=Kind-A => {
    "model:fieldB": 4, 
    "model:fieldA": 3, 
    "model:kind": "Kind-A"
} 

kind=Kind-B => {
    "model:fieldB": 6, 
    "model:fieldA": 5, 
    "model:kind": "Kind-B"
} 

My expectation was:

• in the cND object (Kind Not-Defined): to get an exception because kind is not defined, so I understand that I should not be able to set values for neither fieldA nor fieldB.
• in the cA object (Kind defined as A): I set kind 'A', so I should be able to set fieldA, but not fieldB. So I think an exception should be raised in this case too, or at least, fieldB should be unset while dumping, right?
• in the cB object (Kind defined as B): I set kind 'B', so I should be able to set fieldB, but not fieldA. So I think an exception should be raised in this case too, or at least, fieldA should be unset while dumping, right?

Am I missing something or doing something wrong?

Thanks in advance!
Lluis

[robshakir]

Hi Lluis,

when statements are not currently evaluated by pyangbind - i.e. these validations are not applied, so I expect that you get either fieldA or fieldB defined, but not both together since they are within a choice node.

Could you confirm what you're currently seeing (do you see either fieldA or fieldB being set, but not both?) - as I didn't quite get your output.

Thanks,
r.

[lgifre]

Hi Rob,

The code was a kind of unit testing module to check if when statements were applied or not.
I expected to have in the output of my python unit test one of the fields set, but not both. And to get an exception when you get/set the wrong field, i.e., the one not matching the when statement.
However, since you confirmed that when statement validations are not implemented, it makes sense to get both fields set in all the cases.
Do you plan to implement when statement validations in the near future?

Best,
Lluis

[robshakir]

I'm currently working on some code in a different language for YANG, so I'm a little pressed for time to add things to pyangbind currently. I do plan to add it at some point, but I just need to get cycles to do so.

[viandox]

Hi,
Found this issue after investigating about napalm-yang for YANG 'when statement' support.
As napalm-yang is supported by pyangbing, the question is: Is there news about this feature ?
Regards,
Pierre

[lgifre]

Hi @viandox,
I'm interested in this enhancement too.
I repeated the test I proposed for this issue (enhancement) on Dec 2016 using current versions of pyang (1.7.4) and pyangbind (0.6.0) available through pip. The enhancement is not still implemented. If you find any alternative/workaround, please, let me know!
Best,
Lluis

[robshakir]

I think the Python3 work that @tarkatronic is working on takes precedence over this feature in terms of the number of folks that have asked. However, if someone would like to start working on this -- I can help advise how it might be implemented within the XPathHelper.

The best place to discuss is probably the #pyangbind channel on the NetworkToCode Slack.

[lgifre]

Hi Rok!
Thank you for that quick answer. I didn't knew about @tarkatronic fork. I'll try to find a timeslot to take a look on it and decide on migrating to @tarkatronic fork.
Best and thank you again!,
Lluís

[viandox]

Thanks Rok, quite the same answer here.
Pierre

[tarkatronic]

To be clear, the work I'm doing is getting merged back into this repository, which remains the primary authoritative fork. So for any work you do, I would definitely recommend forking from here.

[robshakir]

Yes, +1 to @tarkatronic -- we're working to merge this back into this code.

What I meant was that I think keeping the code stable to ensure that we're able to finish this work to get to Py3 compatibility (and improved testing approach) is important. After that, we can start to evaluate the feature requests that can be added.

[viandox]

Understand. Will wait until this work released.

[faraazc]

+1

@robshakir I am interested in implementing this feature request can you please provide some pointers.