perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Fligor, Debbie writes:

 

my pscheduler problem is specifically between my two new hosts, which are on the same L2 network, and seem to be trying to talk to each other over IPv6, even for IPv4 tests.

pScheduler-to-pScheduler communication is done via HTTP with the protocol selection being based on what /etc/gai.conf on your system is configured to return first for the host name.  If you’re in a dual-stack environment where hosts have A and AAAA records (as opposed to using separate host names like foo and foov6), the default gai.conf will return a v6 address first and the URL fetching library will use that.  The process of setting up a task doesn’t know or care what protocol will be used for the measurement, so even though it looks disjoint, there’s nothing wrong with it.

I did notice in the log entry you posted below that dest-node is forced to be an IPv4 address, which is fine, albeit unnecessary.  The *-node parameters are for forcing communication with pScheduler on a different address and were built to solve the problem of setting up tasks on systems that live in multiple VRFs.

If there’s a known reason two hosts on the same subnet can’t run throughput tests…

There’s no reason you can’t do that.  It’s all IP, and we run tasks that way many times daily.  The only restriction is that in multi-participant tests (e.g., throughput, simplestream), no single instance of pScheduler can serve as more than one of the participants.  You don’t appear to be running into that.

Here is one task:

on host res-dtn in /var/log/perfsonar/psconfig-pscheduler-agent-tasks.log

2019/04/03 13:36:54 INFO guid=744C238C-563F-11E9-8763-FF999454770F task_name=res-perfsonar_0_0 config_file=/etc/perfsonar/psconfig/pscheduler.d/toolkit-webui.json config_src=include task={"archives":[{"data":{"measurement-agent":"72.36.81.132","url":"https://72.36.81.132/esmond/perfsonar/archive/","_auth-token”:******"},"archiver":"esmond"}],"test":{"spec":{"source":"res-perfsonar.techservices.illinois.edu","dest":"72.36.81.132","dest-node":"72.36.81.132","duration":"PT90S","schema":1,"source-node":"res-perfsonar.techservices.illinois.edu","ip-version":4},"type":"throughput"},"reference":{"psconfig":{"created-by":{"user-agent":"psconfig-pscheduler-agent","uuid":"ECA79EF0-F98E-11E8-8308-CE3177A9DBB1"}}},"tools":["bwctliperf3","iperf3","bwctliperf2","iperf"],"schema":1,"schedule":{"until":"2019-04-04T18:36:54Z","sliprand":true,"repeat":"PT600S","slip":"PT600S"}}

on host res-perfsonar, in /var/log/pscheduler/pscheduler.log

Apr  3 13:37:01 res-perfsonar journal: pscheduler-api INFO     Denied 72.36.81.132 POST https://res-perfsonar.techservices.illinois.edu/pscheduler/tasks/f5bc3a93-876f-45e5-9c4c-f734e9f6b278
Apr  3 13:37:02 res-perfsonar journal: pscheduler-api INFO     Denied 72.36.81.132 POST https://res-perfsonar.techservices.illinois.edu/pscheduler/tasks

One thing I just noticed is that the API is a bit inconsistent in how it logs errors.  Many of them include a message that’s logged during debugging but not in the lines you see above, which isn’t particularly helpful.  I’ve opened a ticket to get that improved.  In the meantime, you should be able to find a companion entry with the same GUID in psconfig-pscheduler-agent-transactions.log that will list the error it got back from the server.  Let me know what you find there.

I ran a few permutations of the tests you’re doing manually (as you did) and found that they worked just fine.  Because of that, I suspect this might be a case of pScheduler being told to do something it doesn’t like by pSConfig, either because of a bug there or a GIGO problem.  Either way, we’ll get to the bottom of it.

--Mark