perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Brian Candler writes:
    
    That explains my 'pscheduler result' problem: I should have been asking 
    the lead node.

There's a fix for that, or at least one that makes "result" refuse to work 
with non-leads, in the pipeline for 4.2.1:  
https://github.com/perfsonar/pscheduler/issues/906.  I think I noticed that 
when running down something in one of your earlier emails.

The pScheduler API operates on a mostly-HATEOAS model, which means that once 
you've POSTed a task and get its URL back, the API provides everything you 
need to navigate it.  The  exception is that task URLs don't return 
additional detail by default so they come out looking largely the same as 
when they went in.  The additional detail can be turned on by adding the 
"detail" argument to the URL (e.g., https://ps.foo.org/tasks/abc123?detail).

Because pScheduler uses its own API internally, an instance of the task has 
to exist on all participants.  From an end-user standpoint, all business is 
transacted with the lead participant and the API will never supply a URL you 
shouldn't be using.

    
    3. This implies to me that the archiver, which writes the results to 
    esmond, runs on the lead node - which in this case is the remote node

That's covered in the documentation; see "Lead Participant" under 
"Terminology":  https://docs.perfsonar.net/pscheduler_intro.html 

One of the conceptual changes from BWCTL is that pScheduler's API doesn't 
make third-party testing a special case.  The API fields requests from 
whoever makes them and responds appropriately.  For the limit system's 
purposes, the address that sent the request to the API is called the 
requester (I think you brought that up in an earlier email), but the rest of 
the system doesn't know or care.
    
    This in turn implies that either esmond on the local node must be fully 
    open to writes from the whole Internet (ouch!); or that some sort of 
    access token is given to the remote node to grant it permission to write 
    to the local node.

The usual MO for that is to use authentication keys or open up the Esmond up 
to the IPs of hosts being given tasking that archives to that Esmond server.

We've been asked about having the requesting system handle the archiving 
instead of the lead participant.  I'm not inclined to develop it because it 
adds complexity to the system that could be avoided by making sure there's an 
accessible network path to the archive.


    Debugging on the remote node says archiving was successful:

That ends where I can help you out.  Andy is our resident expert on all 
things Esmond.

--Mark