perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Jean-Michel Barbet writes:

The annoyance is very little, I just wanted to report as it may be
troubling for some people.

 

Well, thanks for reporting it.  I know you did back in April and we never found a solution for it.  These are the things that help us find and fix the deficiencies in our processes.

BTW, I do not know what were the modifications made to jq that need
a special version instead of EPEL's default... Would it be possible
to use again EPEL's jq if the modifications have been integrated ?

 

Backstory:   jq and pyjq were turning integers into floats when they get bigger than (signed) 32-bits.  This caused problems for one of our larger users because things like bandwidths are specified in integer bits per second became invalid after jq processed them, even if those numbers weren’t touched.  I tried asking if they could keep their speeds below 2.1 Gb/s and they declined.  ;-)  Extensive discussion and links to other tickets here:  https://github.com/perfsonar/pscheduler/issues/717.

 

The maintainers of jq did an overhaul of its internal representation of numbers starting in 2018 and switched to arbitrary-precision.  The code was merged into  the main branch in 2019 but there hasn’t been a relase with it (the last one was 2018).  We could build and ship that code, but it would still mean shipping a non-standard jq and I don’t want perfSONAR to be the sole testing ground for it.  Despite the upgrade problem, which is entirely my fault, the patched versions are the better thing to do.

 

Once there’s a released version of jq that functions properly, we’ll start shipping that or take EPEL’s if they provide it.

 

--Mark