perfSONAR User Q&A and Other Discussion

[Brian Candler <>]

On 09/09/2019 19:18, Mark Feit wrote:

4.0.x reached end of life in February and is no longer supported; please upgrade those systems before reporting bugs.

Currently stuck on that due to the need to visit data centres to reinstall machines (no remote upgrade CentOS 6->7 possible), but yes, that's the plan when time allows.

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.

But when you add a throughput test in the GUI, and accept the default bi-directional test, then I believe it works the way I described.

  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.

Of course, that's clear - all participants must agree.  But I think there's something the pscheduler documentation (at least the bits I've read) doesn't make clear.

It's clear that when you run a single test, one of the nodes is chosen to be the lead node that's responsible for coordinating the slot, collating/merging the results, and archiving them.  It's also implied that the lead node is likely to be the --source node (it actually says this is true for "many tasks", but not specifically for throughput)

What wasn't clear to me is that if you set up a repeating test, that the lead node also carries the *persistent* state and is responsible for the repeated scheduling of future runs.

When I go into the GUI on my system, and use it to create a repeated test between A and B, I was expecting all the state to be stored on my node.  If I turn my node off, or wipe it and reinstall perfsonar from scratch, I would have expected that test not to run any more.

But from what I've now discovered, I think that expectation was wrong.  Some persistent state is created on my host A for making tests from A to B, but some on the other host B for tests from B to A - I'm effectively adding a cronjob to someone else's system.  And if the owner of node B were to reinstall perfsonar, half my scheduled test would stop working (at least until psconfig_pscheduler_agent notices)

I'm not saying this is necessarily bad - only that it would never have occurred to me that it might work this way.

Perhaps it could be clarified here: https://docs.perfsonar.net/pscheduler_intro.html#term-lead-participant

Here's my suggestion:

Lead Participant The pScheduler server where a task should be submitted. It will become responsible for contacting other participants, making scheduling decisions based on gathered information, archiving results, and continuing to schedule further runs of repeating tasks.

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.

I will - thanks.

Cheers,

Brian.