perfSONAR User Q&A and Other Discussion

[Casey Russell <>]

Shoot, I should have pointed out... 

After you do that, be sure to run /opt/perfsonar_ps/mesh_config/bin/generate_configuration  on all your mesh hosts to force them to pull the new .json file and they should restart their testing accordingly

Casey Russell

Network Engineer

Kansas Research and Education Network

2029 Becker Drive, Suite 282

Lawrence, KS  66047

(785)856-9820  ext 9809

On Tue, Sep 29, 2015 at 9:48 AM, Casey Russell <> wrote:

Group,

Just in case other mesh config users encountered the surprise this morning as well.  I came in this morning to all my mesh hosts having stopped their testing during the night.  My Maddash dashboard was fading to yellow quickly.  The solution was simple, but maybe not obvious to you, unless you've followed the changes to the directory structure in the new 3.5 version of PS. 

If you, like we, keep your .json file for your mesh config hosts on a PerfSonar machine (our central MA in our case), you likely hosted it in your regular PerfSonar directories.  In the old 3.4 directory structure, this meant you stored your <mesh_name>.json file in the /opt/perfsonar_ps/toolkit/web/root/ directory.

After the upgrade to 3.5 this director is no longer used.  The new 3.5 web pages are served from the /opt/perfsonar_ps/toolkit/web-ng/root/ directory.  So you'll need to regenerate your .json file and make sure it gets put into the new web-ng/root directory tree instead of the old web/root  directory tree.

As I said, easy fix, but maybe not obvious if you weren't watching some of the Release Candidate discussions and documentation.

Casey Russell

Network Engineer

Kansas Research and Education Network

2029 Becker Drive, Suite 282

Lawrence, KS  66047

(785)856-9820  ext 9809

On Tue, Sep 29, 2015 at 9:38 AM, Roderick Mooi <> wrote:

OK great! I started reviewing all the .conf vs .conf.rpmnew files to understand the changes and any effects they may have. Some of our nodes are from 2012 and have been upgraded from 3.2 originally so effects like this might warrant a complete re-install. From your side - I’m pretty impressed with the backwards compatibility and upgrade processes so far (e.g. this issue seems to be the only major issue so far after all our nodes auto-updated yesterday).

Good job!

Regards,

Roderick

On 29 Sep 2015, at 3:22 PM, Andrew Lake <> wrote:

I see there is a commented out “testports 0” higher up - maybe it’s reading that as well by mistake?

Yep, I think that’s it. The tesport range was changed from 0 in early 2013. Your initial owampd installation must be from before then so it still has the commented out version. We’ll get the script updated so it ignores comments.

 

PS while we’re on this file, please advise I see that 

dieby 5

is now set whereas in our previous versions it was commented out.

The surrounding comment says that the default is 30. Is that still the case or is the default now 5?

Either way, which setting do you recommend (or what are the conditions for deciding)?

The default is now 5 (as in if you deleted that line entirely the default would be 5). I think related to above you have an older owampd installation that has gone through it’s fair share of upgrades and as such comments might be a bit dated. 

 

Thanks

On 29 Sep 2015, at 2:56 PM, Roderick Mooi <> wrote:

Hi Andy

Here you go. testports are set but don’t look suspicious...

Thanks,

Roderick

<owampd.conf>

On 29 Sep 2015, at 2:31 PM, Andrew Lake <> wrote:

Hi Roderick,

Could you send me your /etc/owampd/owampd.conf? My best guess is that /opt/perfsonar_ps/toolkit/scripts/system_environment/configure_regular_testing, which is run on update, somehow managed to do that. It sets the receive_port_range to match the “testports” in owampd.conf if set. There might be something different about your owampd.conf file that is tripping it up. 

Thanks,

Andy

On Tue, Sep 29, 2015 at 4:43 AM, Roderick Mooi <> wrote:

Hi again

The problem seems to be with these lines added to regular_testing.conf:

#Default testports set by automated toolkit script

<default_parameters>

   type  powstream

   receive_port_range 0

8760-9960

</default_parameters>

The 0 and the 8760-9960 on a new line.

Changing to this resolved the problem and the service is running now:

   receive_port_range 8760-9960

Anything else we need to do?

Thanks,

Roderick

On 29 Sep 2015, at 9:16 AM, Roderick Mooi <> wrote:

Hi Andy and team

After restarting my updated 3.5. hosts the regular testing service is shown as not running. In the ‘regular_testing.log’ file I get the following error:

2015/09/29 09:01:36 (8074) ERROR> ConfigFile.pm:101 perfSONAR_PS::RegularTesting::Utils::ConfigFile::parse_file - Line 309 malformed
2015/09/29 09:01:36 (8074) ERROR> daemon:84 main:: - Problem parsing configuration file: Line 309 malformed

line numbers vary per host.

Please advise.

Otherwise looking good - great job!

Best regards,

Roderick

 

On 28 Sep 2015, at 6:38 PM, Andrew Lake <> wrote:

Dear perfSONAR Community,

The final version of perfSONAR 3.5 is now available! Existing users may run "yum update" to get this new release. Alternatively, if you have automatic updates enabled, you should get the update within 24 hours. It is recommended, though not required, that you reboot the host after the update to ensure you are running the latest packages and kernel. For new Toolkit installs, you may find our ISOs at the following link:

http://downloads.perfsonar.net/toolkit/

For more information on install options, updating and using the software please see http://docs.perfsonar.net.

About 3.5:

Version 3.5 is intended to be an important first step toward increasing the usability, automation and ease of large-scale deployments for existing perfSONAR users. Read more here: https://www.internet2.edu/news/detail/8866/ Some specific changes in this release include the following:

- A brand new web interface that addresses many of the UI concerns voiced in the community over the past few years. You will be presented with this interface the next time you visit the toolkit after the update is applied. See the documentation for some screenshots of the new interface: http://docs.perfsonar.net/install_config_first_time.html#accessing-the-web-interface. For this release you will also be able to visit the previous interface by navigating to http://hostaddress/toolkit-old in your web browser.

- Support for alternative installation methods to the Toolkit ISO on both CentOS and Debian/Ubuntu. This allows for more flexibility in deployment, especially for large deployments and/or those running lower cost hardware. See http://docs.perfsonar.net/install_options.html in our documentation for more details.

- Enhanced central management and “auto-configuration” features to aid in the deployment of a large number of hosts. See our documentation at http://docs.perfsonar.net/#managing-multiple-perfsonar-hostsfor more details.

In addition to above there are of course the usual round of bug fixes and performance improvements that go hand-in-hand with a release. Thank you to all in the community who helped us to identify and solve those over the past few months. Full release notes can be found at http://www.perfsonar.net/release-notes/version-3-5/

Also, please take this chance to review our hardware advice page: http://www.perfsonar.net/deploy/hardware-selection/hardware-advice/. Version 3.5 should NOT introduce any significant hardware resource requirements over version 3.4, but as test meshes continue to grow many of the requirements such as memory, are becoming “stricter” minimum requirements than in the past so this is a good opportunity to verify your setup. In particular, note that we recommend a minimum of 4GB of RAM for a perfSONAR Toolkit host.

As always, please let the perfSONAR team know if you have any questions and we look forward to your feedback.

Thank you,

The perfSONAR Development Team

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.

Please consider the environment before printing this email.

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.

Please consider the environment before printing this email.

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.

Please consider the environment before printing this email.

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.

Please consider the environment before printing this email.

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.

Please consider the environment before printing this email.

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.

Please consider the environment before printing this email.