perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

(This one will be shorter, I promise.)   (But not by much, apparently.)

Brian Candler writes:

    Does this mean that all test results get put into postgres before being 
    handed over to the archiver?
    
    I can see benefits of that, especially where the archiver is remote and 
    may not always be online or reachable. ISTR that perfsonar had some sort 
    of file-based queue before, and this sounds like a a much more robust 
    way of processing the data.

Yes, it does mean that, and you nailed exactly why it was done that way.  
There is additional sophistication built in, too.  For any task, the runs can 
be archived to any number of archivers configured any number of different 
ways (e.g., two esmonds on different hosts with different authentication 
keys, one RabbitMQ and an HTTP).  All of this is done reliably by the 
pScheduler server, with each archiver able to make decisions about how often 
to retry and when to give up.  Plus you get diagnostics that can be queried 
through the REST API (and, by extension, the CLI).
    
    I get the impression that a passive node - one which never schedules a 
    test by itself, and never takes the "lead" role - isn't going to be 
    using the database very much, except for keeping an inventory of 
    available test modules (which is essentially static).

One of the the big architectural changes is that every pScheduler node, even 
the non-leads, maintains an appointment book (which I call the “schedule” or 
“timeline”) of every run.  This is used to make sure tests that aren’t 
supposed to overlap don’t and also as a diagnostic tool so you can look at 
how congested the timeline is for planning your testing.  (The visualization 
of this is why we include GNUPlot.)
    
    Basically I want to be able to install a handful of packages on an 
    existing server to have it participate in some sort of periodic network 
    tests in addition to its normal workload.

That’s where something lighter like BWCTL wins out.  The trade-off is that 
when somebody writes plug-ins that do new measurements you find interesting, 
you’re going to be out of luck.  I spent quite a bit of time studying BWCTL 
before recommending we make the change.  A lot of the things we wanted it to 
do would have been difficult  and not pretty.

      Installing ~200 packages [^1] is too intrusive.

FYI, ~55 of those packages (~28%) are pScheduler or tool dependencies (iperf, 
traceroute, etc.).  The packages are finely sliced and diced to allow 
customization.  You can, for example, render a node incapable of doing 
throughput testing (or even knowing that kind of testing exists) by not 
installing the throughput test or any tool plugins that can do that test.  

    There's no pscheduler in homebrew yet, and it sounds like it might be 
    difficult to do given the number of dependencies.

Probably not; it’s just not something we’ve addressed yet.  I’m pretty sure 
most of what we depend on is available and don’t know enough about Brew to be 
useful.  This is one of those side projects on our not-officially-supported 
list that we do as we have time.
    
    My concern is how long before bwctl fallback support is stripped out of 
    perfsonar - if that happens, bwctl's utility will be limited to ad-hoc 
    testing.

That was in my TechEx slide deck:  backward compatibility was done to ease 
the transition to 4.0 and disappears in 4.1.  If enough people clamor for it, 
we might keep it around a bit longer.  The aforementioned hacks violate 
several of the key principles of pScheduler’s architecture and I want them 
out of the system as soon as possible so they don’t get abused.

    Alternatively, maybe I could write a pscheduler plugin which runs a 
    one-participant test talking to an iperf3 server (i.e. assumes "iperf3 
    -s" is already running at the far end).  This loses the ability of bwctl 
    to prevent two tests being scheduled concurrently, but for occasional 
    tests it might be good enough.

That’s pretty much what the backward-compatibility plugins do, but within the 
framework of the existing test types.  You may end up having to write 
completely different test plugins to go with it because of its 
single-participant nature, but that could be based on the existing throughput 
plugin.  We’ll be more than happy to get you pointed in the right direction, 
but we don’t have the resources to keep it as part of the project.

    Maybe getting rid of the hard dependency on gnuplut would 
    help, which is where this thread started :-)

I’ve found a solution to that problem for CentOS that cuts the dependencies 
down to four packages and about 5M.  See the ticket Antoine referenced in his 
last email.

--Mark