perfSONAR User Q&A and Other Discussion

["Jennewein, Douglas M" <>]

Wow — that did it! Thanks, Andy!

-- 
Doug Jennewein

Director of Research Computing

The University of South Dakota

On March 1, 2017 at 8:59:37 AM, Andrew Lake () wrote:

Hi,

A couple things:

- Try adding a ‘/‘ at the end of the measurement_archive url so it is http://perfsonar-management.usd.edu/esmond/perfsonar/archive/. This is silly, and I only know this because I just bumped into this the other day with someone else running 3.5.1 and a bug I thought was fixed in the 3.5.1 line of code, but looks like maybe it wasn’t.

- Also, you should probably update your other two measurement_archive blocks to point at your central MA unless you only want your throughput tests to go there. Right now as it stands your traceroute tests you have configured will still just go to localhost.

Hopefully those changes fix things, if not let me know and I can help debug some more.

Thanks,

Andy

On March 1, 2017 at 9:48:58 AM, Jennewein, Douglas M () wrote:

We are still hitting a few snags setting up our central MA.

 

perfsonar3.usd.edu is a measurement host, participating in a mesh defined at https://perfsonar-management.usd.edu/usd-mesh.json (attached). It’s regulartesting.conf is also attached and contains an entry for the measurement archive defined in usd-mesh.json.

 

perfsonar-management.usd.edu hosts our mesh config (which is working great) and the central archive, which doesn’t appear to hold any data. Performing a GET on http://perfsonar-management.usd.edu/esmond/perfsonar/archive returns an empty JSON object.

 

We are authenticating by IP and created an ssmond user for perfsonar3 by running the following on perfsonar-management:

python esmond/manage.py add_user_ip_address perfsonar3_user 192.236.39.113

 

Do you see any obvious omissions or misconfigurations in any of this?

-- 
Doug Jennewein

Director of Research Computing

The University of South Dakota