Consider removing localhost MA from default meshconfig-agent-tasks.conf

[arlake228]

Currently the default meshconfig-agent-tasks.conf contains a default MA pointing at localhost that just needs an auth key filled-in/removed. This is problematic on anything running testpoint since they don't have an MA and people likely won't remove it. Should consider the following:

• Remove from default and have -core package add it back
• Remove from default and have core create a default archiver (need to check whether this would work in reverse test case where localhost not lead). This would also grab on-demand tests which may not be desirable.
• Remove default, set configure_archives to 1 and have GUI add MA for each test it adds, essentially making all MAs at the test level instead of applying to all tests set by meshconfig

Also need to consider upgrade paths of whatever we choose since options have differing implications.

[igarny]

I have come across this event in my logs, which I believe is related to the problem stated here:

Mar 7 09:46:48 psps-test2-mgmt archiver WARNING 2175121: Failed to archive https://psps-test2-mgmt.rrze.uni-erlangen.de/pscheduler/tasks/138cbe59-0277-4333-aaa3-36b73f4b056f/runs/fe5a05 c7-aaab-4ca7-9da7-e5ea3aeaf082 to esmond: Unable to post metadata to http://perfsonar-lab-vm.ilab.umnet.umich.edu/esmond/perfsonar/archive/: ('Connection aborted.', error(111, 'Connection refused'))

Mark verified it and reported it is not related to pscheduler itself perfsonar/pscheduler#339

[mfeit-internet2]

The question is why the RRZE system is trying to archive to UMich.

[arlake228]

That’s how reverse tests work. Umich has a local MA configured, so any test the Umich creates where the remote host is the lead will write back to Umich. My guess is that its getting connection refused because of the NAT on the German host or I guess could be a firewall on the Umich side (though the former seems more likely since I can get to teh MA fine from elsewhere). Either way, not a code issue.

On March 7, 2017 at 8:17:55 AM, Mark Feit (notifications@github.com) wrote:

The question is why the RRZE system is trying to archive to UMich.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/perfsonar/mesh-config/issues/51#issuecomment-284718504, or mute the thread https://github.com/notifications/unsubscribe-auth/AAmv44Dt1APJeNFsFTwWAg0RtyK-BBnMks5rjVkAgaJpZM4L1RjG .

[igarny]

there are no custom FW rules on my host either

I am able to connect on http port of Umich host Please note that nevertheless my host is using the default gw interface, which is NATed

[root@psps-test2-mgmt ~]# curl http://perfsonar-lab-vm.ilab.umnet.umich.edu/esmond/perfsonar/archive/ | head -c 1000 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 101 5494 0 5494 0 0 2862 0 --:--:-- 0:00:01 --:--:-- 3059[{"url":"http://perfsonar-lab-vm.ilab.umnet.umich.edu/esmond/perfsonar/archive/029b3b73cec541baa8046a3f7f49796f/","metadata-key":"029b3b73cec541baa8046a3f7f49796f","subject-type":"point-to-point","event-types":[{"summaries":[],"time-updated":null,"base-uri":"/esmond/perfsonar/archive/029b3b73cec541baa8046a3f7f49796f/throughput-subintervals/base","event-type":"throughput-subintervals"},{"summaries":[],"time-updated":1486477200,"base-uri":"/esmond/perfsonar/archive/029b3b73cec541baa8046a3f7f49796f/failures/base","event-type":"failures"},{"summaries":[],"time-updated":null,"base-uri":"/esmond/perfsonar/archive/029b3b73cec541baa8046a3f7f49796f/packet-retransmits/base","event-type":"packet-retransmits"},{"summaries":[{"summary-type":"average","uri":"/esmond/perfsonar/archive/029b3b73cec541baa8046a3f7f49796f/throughput/averages/86400","time-updated":1101 5494 0 5494 0 0 2861 0 --:--:-- 0:00:01 --:--:-- 3057mond/perfsonar/archive/029b3b73cec541baa8046a3f7f49796f/throughpu curl: (23) Failed writing body (2698 != 2896)

[igarny]

the way I read you guys is, that this is a non-issue, since the Umich host has triggered the test with correct specification for their local MA. This is simply a connectivity issue for my host not being able to connect there and this behavior is expected on remotely triggered tests.