perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Brian Candler writes:

OK, I'm sold on the idea of better queuing of results via postgres.  It means I'd be happier to throw up a shared esmond instance (in a VM say), and have test endpoints without local measurement archives.  Dropping esmond from those nodes would more than compensate for adding postgres.

 

That’s something you could have done in 3.5.  In 4.0, it looks the same because we didn’t want to disturb the way Meshconfig works. The future of that program is one of the topics for our next developers’ get-together.

Regarding the terminology of "lead participant": how does this work for third party tests? For example, http://fasterdata.es.net/performance-testing/network-troubleshooting-tools/pscheduler shows this example:

pscheduler task throughput --source send_host --dest receive_host --duration PT30S

Is the "lead participant" the send_host, or the host which runs the "pscheduler task" request? If the latter, then this test obviously has three participants.

 

The requester doesn’t count as a participant because it’s not involved in the measurement process.  Because everything is done through the REST API, everything third-party; the CLI or other program that did the asking having been invoked on the local host is just a pleasant coincidence.  (There’s a little bit of a kink that comes up with using the CLI to ask other hosts to run tests, but for the time being it’s an edge case that most people won’t run into.  The program already has provisions for dealing with it.)

 

In your example, the throughput test defines the source as participant 0 and the destination as participant 1.  That’s completely arbitrary; it could have been done in reverse order and everything would work just the same.  pScheduler gets the list back and crowns the first host in it the lead participant without any understanding of what roles they play in the measurement.  Lots of things in this system are very tightly encapsulated.

I wonder if the new architecture allows a different way of working: could you have a central node which talks directly to all the pschedulers and registers test schedules with them?  Then you could have a central GUI where you could add a test from any X to Y, alongside a single measurement archive which contains all the results.

 

That’s not only allowed, it’s encouraged.  pScheduler can be involved in those types of things from multiple systems at the same time.  It’s another of those doesn’t-know, doesn’t-care situations.  We’ve talked to a couple of people working on projects that need to do measurements, and pScheduler will allow them to user perfSONAR as a building block.

 

So, Brian, what can I do to get you to drive home today in a shiny new 2017 pScheduler?  ;-)

 

--Mark