perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Daniel Spisak writes:

 

So I have made some progress on my deployment and come across a problem with pscheduler and the limits. 

 

I tried to edit the limits files bogon block to exclude the 172 space since I use this in my test build. However, anytime I tried running a pscheduler command manually it would fail it and claim it was still matching against the bogon block.

 

Can you post the exact output from that and a copy of your limits file and let me know what version of the software you’re running?

 

The default limit file as it stands now (see the sources at https://github.com/perfsonar/toolkit/blob/master/etc/default_service_configs/pscheduler_limits.conf ) has an exclusion for the 172 block, so if you’re using an older one that you changed, you might want to incorporate the new stuff.

 

The “bogons” identifier should contribute to the “hostiles” classification, which is probably what you’re tripping.  Also be aware that changes to the limits files can take as long as 15 seconds to be noticed.

 

So I said screw it and removed the entire bogon block from the limits JSON and then I could run manual pscheduler commands. However, when I do a pscheduler monitor, it shows all of the scheduled tests as failing and I can see my manual tests succeeding. 

 

If you’re seeing runs where the state is “Non-Starter,” that’s an indication that the scheduler wanted to schedule the run and couldn’t because there wasn’t time available on all participants’ timelines _or_ because the run wouldn’t have passed the limits at the proposed times.  (Limits get checked once when the task is first submitted and again when each run is scheduled.  There are a few types of limits that can be used to deny scheduling at certain times.)  Because pScheduler has a timeline (where Regular Testing would do its own thing and try to make measurements when their times came up), runs are laid out up to 24 hours in advance and must meet the limits when they’re scheduled.

 

If you’re seeing runs with a state of “Failed,”, that means the task passed the limits when it was first submitted to the system and each of the runs passed the limits again when scheduled _and_ the run started, but something unrelated to limits caused it to fail.  There is sufficient information stored in the system to determine what happened and command-line tools to pull the information out.

 

If you’d like to drop me a line privately, we can jump on video and have a look at what’s happening on your system.

 

--Mark