perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Brian Candler writes:

Just to make things more fun, I also had a third (completely different) problem with inbound tests not working from another host.  That remote host is running ps-toolkit 4.0.2 under CentOS 6.

4.0.x had a number of IPv6-related problems, some involving addresses, that were fixed in later versions.  4.0.x reached end of life in February and is no longer supported; please upgrade those systems before reporting bugs.

 

I added some debugging, and found that this post is being made to /pscheduler/tasks on the *remote* host.  It seems that if I request in my local GUI to have a regular throughput test to a third-party host, the scheduled task for inbound throughput is created on *their* system.  That is: I have to trust that other system to run the scheduled task on my behalf, at the interval I requested!

That would be the case no matter what because throughput requires the cooperation of all participants to avoid conflicts in testing.  If you want your system to be the lead, throughput offers a “reverse” parameter that will do everything the same way but sends data from the destination to the source.  That won’t change the fact that if the other system decides it doesn’t want to participate in your test, it won’t happen.

 

< HTTP/1.1 500 INTERNAL SERVER ERROR
...
Unable to determine participants: Can't find pScheduler or BWCTL on [A:A:A:A::45]

That message is a remnant of a hack in 4.0 that allowed pScheduler some limited interoperability with BWCTL.  The part of the test plugin being called there is supposed to derive a participant list based only on the data in a test specification; we had to make it reach out to other systems to see what was available for BWCTL to work.  It’s treated as a 500 because the only thing that should cause it to die under normal circumstances is a failure of the program itself.  I’d been wanting to get rid of this since the day I put it in; the last of it was removed in 4.2.0.

 

Aha.  That would have been a much more helpful message to see.  I've made a PR to fix that - clearly it ought to be logged.  Now it is:

That crosses over to Andy’s department; he’ll probably pull that one in.

NB:  When submitting PRs, please have a look at the way we do versioning and branching to select the right branch; this project no longer commits code to the master branch.

 

On the 4.0.2 node, /var/www/pscheduler-server/pschedulerapiserver/tasks.pyc exists but not tasks.py.  That's *really* annoying, as I can't look at or modify the source.

At some point, I think I’d packaged only the PYCs because a few of our users preferred not having source code on their systems where they can avoid it.  I’ll revisit that.

--Mark