The edit-config (shown) gets a “must-violation” error on confd 6.3 - i686 (which is correct since 0.1 is less than 0.2 ) but the same edit-config is accepted on confd 6.3 - powerpc version and the record is successfully created in cdb. The YANG fragment is shown below.
Question: What is being used by confd for xpath evaluation? Is this some /usr/lib/libxml2.so version issue on the target linux box ? Thanks
container iosThresholds {
description "";
list threshold {
key name;
description "";
tailf:callpoint iosThresholdsHook { tailf:transaction-hook object; }
must "(number(maxPower) - number(minPower)) <= number(/ggios/iosConfiguration/iosMaxSignalRange)"
{ error-message "Specified values exceed the maximum allowed power range"; }
leaf name {
type string { length "1..20"; }
mandatory true;
description "";
}
leaf descr {
type string { length "0..64"; }
default "An IOS power threshold value to monitor";
description "";
}
leaf minPower {
type string;
default "-20.0";
must "number(.) >= number(/ggios/iosConfiguration/iosMinSignalPower) and number(.) <= number(/ggios/iosConfiguration/iosMaxSignalPower)";
description
"Identifies the minimum power (dBm) value for monitoring threshold
crossings on the assigned port.";
}
leaf maxPower {
type string;
default "5.0";
must "number(.) <= number(/ggios/iosConfiguration/iosMaxSignalPower) and number(.) >= number(/ggios/iosConfiguration/iosMinSignalPower)";
description
"Identifies the maximum power (dBm) value for monitoring threshold
crossings on the assigned port.";
}
leaf hysteresis {
type string;
default "1.0";
must "number(.) >= number('0.2')" { tailf:dependency '.'; }
description
"Identifies the hysteresis gap (dB) value for monitoring threshold
crossings on the assigned port. This value helps avoid
spurious events caused by power whipsaw from signal noise.";
}
}
Works on the PPC target I have.
From ConfD 6.3 and later releases you have some some useful XPath dev tools in the C-style CLI that you can try on your target:
Thanks I tried the CLI and sure my target failed the xpath must! But why ?
My PPC linux has a native floating point unit on it. Is there a compile option I could have missed, when I recompiled libconfd for to use 0.9.8 version of openssl ?
Interestingly the xpath eval shows following on my ppc box in confd_cli:
Also the return values are more ridiculous when running confd as “confd -smp 4”. The return value is 25 million 25000000 for xpath eval “number(‘0.5’)” and actually for any float value!
The following output is when using confd without -smp flag:
Also, have you considered using the YANG decimal64 built-in type instead of strings?
For example:
leaf hysteresis {
type decimal64 {
fraction-digits 1;
}
default 1.0;
must ". >= 0.2" { tailf:dependency '.'; }
description
"Identifies the hysteresis gap (dB) value for monitoring threshold
crossings on the assigned port. This value helps avoid
spurious events caused by power whipsaw from signal noise.";
}
I believe the weird results here could be due to your kernel and/or OS libraries not matching your HW. The ConfD ppc build assumes HW floating-point support, and you say that your CPU has a FPU - but if your kernel/libraries are not aware of that, the FPU will not be properly initiated and managed, causing random results for floating-point operations (as opposed to the case where you don’t have a FPU, where they will cause a kernel trap).
So check your kernel configuration, in particular CONFIG_MATH_EMULATION, and whether your glibc is built with -msoft-float.
So I tried the suggestion to use decimal64 instead of string and it didn’t work either. The problem is still the same - xpath must statement fails due to floating point value comparisons on ppc platform. This xpath works just fine on i686.
So, short of looking further into glibc build issues on my ppc platform - i’ll just use tail:validate callback to do the same validation of data values.
Yes, the XPath definition of “number” is floating point. With decimal64, you could use the Tailf-proprietary compare() XPath function in your must expression - see the section XPATH FUNCTIONS in the tailf_yang_extensions(5) manual page.
However looking back at your original must statement, I’m afraid I can’t see how to express it using compare() - there’s no support for arithmetic on the internal values.
Using decimal64 could still be useful - you get syntax check and parsing done by ConfD.