perfSONAR User Q&A and Other Discussion

[Pete Siemsen <>]

Thanks, Phil! (Of course I remember you, though USC was a long certainly a long time ago)

We added your cheat sheet to our local list of truthiness documents about perfsonar/maddash. Thanks, it's quite good.

Ok, you asked for some feedback, so here goes...

It seems that nuggets of information are spread around in different MaDDash documents. It would help if the documents reliably used explicit terms. For example, in my simple case, there is machine on which is installed the "perfsonar-centralmanagement" software, and several other machines on which are installed the "perfsonar-testpoint" software. The first is sometimes called the "measurement archive" or the "web server" or the "server" or "the host running the dashboard". The others are sometimes called "measurement nodes", "testpoints", or even "agents".

I find the term "agent" to be particularly confusing. There are Unix processes named psconfig_maddash_agent and psconfig_pscheduler_agent that run on the perfsonar machines. To avoid confusion, would you consider changing your cheat sheet to change "agent" to "testpoint" or "measurement node"? This is not your fault - even the doc at http://docs.perfsonar.net/psconfig_intro.html has a picture that implies that the machines themselves are "agents".

We ran into issues because we didn't understand (and still don't) how bundles interact. Is it ok to install the testpoint bundle an a machine that already has the "toolkit" bundle? Is the centralmanagement machine a de facto testpoint? Can a "toolkit" be a "testpoint"? I appreciate that your spreadsheet says, like, "ONLY load perfsonar-testpoint bundle", but I wonder why. It's good advice, because we ran into some dependency problems. I personally wouldn't mind if there were just one "perfsonar" bundle that has all the code.

One thing I really like about your cheat sheet is that after a command, it suggests how to verify that the command worked. That is invaluable. We learned to check log files carefully after most changes.

I have a suggestion for the section on the central management server. It starts with "Setting up the MaDDash server and esmond database system", and proceeds nicely, but then the command "psconfig remote add “https://ip-address-of-archive/psconfig/name-of-file.json”" appears. It's not clear that the command is executed on testpoints, not on the central management node.

Thanks very much for the troubleshooting section and the optional edits section!

Cheers,

-- Pete

On Tue, Jul 2, 2019 at 5:00 PM Phil Reese <> wrote:

Hi Pete,

(remember me from  your USC days, looong ago?)

We've been struggling with this for some time too.  The doc that Andy recently shared opened a lot of doors for our work.  I know it was pulled together very quickly and has some issues, but it had enough core info to allow a breakthrough of the morass we were in before hand.

I've assembled our own quick start document, HEAVILY based on the original doc Andy shared, you can take a look at it at:

https://docs.google.com/document/d/1jH7sLST1l9l9eyG6_0oe82pdl-eOZYYz4poOcQgn-kE/edit?usp=sharing

I think we've a reasonable handle on things now.  We're planning a large 30+ agent deployment across our relatively new backbone to allow our networking and monitoring folks to know of internal issues before the emails from our users start.

We're in the process of deploying 10 agents right now.  This is to shake out the deployment process and allow us to try a few different bits of hardware before we go for the whole 30+ agent deployment.

We expect to PXE boot the agents in the field.  Toward that end we've developed kickstart files for Centos systems and would be happy to share them if anyone is interested.

Hope this of help you and any others reading.  PLEASE do provide feedback and suggestions.

Phil

On Tue, Jul 2, 2019 at 1:22 PM Pete Siemsen <> wrote:

We are two people trying to get a new MaDDash install working. We haven't done this before. We think we're close.