perfSONAR User Q&A and Other Discussion

[Michael Johnson <>]

Hi Jon,

Generally speaking, you're right that for "display related" things, it doesn't make 
much difference what is installed on the end hosts. However, what is "display related" 
is not always obvious.

pscheduler-archiver-esmond is responsible for taking results from pscheduler 
and inserting them into Esmond. It is also responsible for telling Esmond 
what summaries to create. Whether the correct summaries exist or not will 
obviously affect the ability to display those values, so it's unavoidable 
that there will be impact.

For the most part, when we add new features/bugfixes to the graphs, they 
won't be affected by what's running on the testpoints, except when there are 
changes needed to how the data is stored, or having the archiver add new 
fields, or summaries, etc.

The graphs try to let things fall back gracefully when certain things are 
missing, but there are practical limits to this.

- Michael

On Wed, Aug 23, 2017 at 08:49:28AM +0200, Jon Clausen wrote:
> Hi
>
> I can confirm that it works as described.
>
> The real issue here is probably me not quite understanding how things work
> together:
>
> I updated the testpoint machines yesterday (which brought
> pscheduler-archiver-esmond to 1.0.1.1-1) and this morning the 1-day/3-day
> ranges show the ping latency graphs as expected - with the graphs 'starting'
> at the point of package update.
>
> That the graphs depend on what's installed on the testpoint systems does
> surprise me though. The mesh configuration defines one central measurement
> archive for all tests, so that all the data would be collected at one
> location.
> For this reason, I had expected everything 'display related' to depend on
> what's installed at the measurement archive only.
>
> I guess I need to read some more, to better understand how this all works.
>
> br
> /jon
>
> oh, and thanks for the explanation about npm and packaging.
>
> On 2017-08-22 14:01:41 (-0400), Michael Johnson wrote:
> > Hi Jon,
> >
> > I just tested this on a 4.0.1 host which I upgraded from 4.0. As far as I can 
> > tell, it's working correctly.
> >
> > However, the main part of the fix for the ping latency issue was in the 
> > pscheduler-archiver-esmond package. There was a missing summary window. Also 
> > note that once you upgrade that, you should see values from that time forward 
> > (it doesn't retroactively add the missing window on old data).
> >
> > What version is your perfsonar-archiver-esmond?
> >
> > On the test host I mentioned, I see:
> > Version     : 1.0.1.1
> >
> > By the way, it's expected that "bundle.js" on git may not match the installed version. 
> > This is because bundle.js  is built using npm and the results are then committed to github. 
> > However, during the RPM build process, the "bundle" file gets rebuilt.
> >
> > Thanks,
> > Michael
> >
> > On Tue, Aug 22, 2017 at 10:57:47AM +0200, Jon Clausen wrote:
> > > Hi
> > >
> > > We have the same issue on our CentOS7 pS 4.0.1 measurement archive:
> > >
> > > 'Ping' latency graphs are not shown with 'report range' shorter than one
> > > week.
> > >
> > > Looking at the patches at
> > > 
> > https://github.com/perfsonar/graphs/commit/eb560cca62634fc587be297769a8cf3d17bcb1fd
> > > and comparing with the files on the system, there are pretty big
> > > differences (the sections of code are at different line numbers) but it's
> > > clear that the 'bundle.js' (for example) has not been 'patched':
> > >
> > > [jac@psma01 ~]$ grep WEIRD /usr/lib/perfsonar/graphs/html/public/bundle.js
> > >                                //console.log("WEIRD: multiple summary
> > >                                //windows found. This should not happen.",
> > >                                //win);
> > >
> > > The file;
> > > [jac@psma01 ~]$ rpm -qf /usr/lib/perfsonar/graphs/html/public/bundle.js
> > > perfsonar-graphs-4.0.1-1.el7.centos.noarch
> > > [jac@psma01 ~]$ ls -l /usr/lib/perfsonar/graphs/html/public/bundle.js
> > > -rw-r--r--. 1 perfsonar perfsonar 6045058 Aug 11 17:23
> > > /usr/lib/perfsonar/graphs/html/public/bundle.js
> > >
> > > The package was updated 2017-08-06;
> > > [jac@psma01 ~]$ sudo grep perfsonar-graphs /var/log/yum.log
> > > May 17 12:26:38 Installed: perfsonar-graphs-4.0.0.2-1.el7.centos.noarch
> > > Aug 16 08:00:01 Updated: perfsonar-graphs.noarch 4.0.1-1.el7.centos
> > >
> > > And currently there are no updates available;
> > > [jac@psma01 ~]$ sudo yum update
> > > Loaded plugins: fastestmirror
> > > Loading mirror speeds from cached hostfile
> > > * base: mirror.nsc.liu.se
> > > * epel: ftp.crc.dk
> > > * extras: mirror.nsc.liu.se
> > > * perfSONAR: mirror.in2p3.fr
> > > * updates: mirror.nsc.liu.se
> > > No packages marked for update
> > >
> > > Have the patches simply not been applied to the rpms, or am I
> > > misunderstanding something?
> > >
> > > br
> > > /jon
> > >
> > > On 2017-07-24 11:30:17 (-0400), Michael Johnson wrote:
> > > > Hi Larry,
> > > >
> > > > Thanks for reporting this; I've never seen it before, but I just 
> > reproduced it, and created an issue in our tracker for it:
> > > > https://github.com/perfsonar/graphs/issues/102
> > > >
> > > > Regarding the 3.5 hosts, I don't readily have one available for testing, 
> > can you send me an example? I can look at it, though I rather doubt we'll be making 
> > updates to the old graphs at this point.
> > > >
> > > > Thanks,
> > > > Michael
> > > >
> > > > On Thu, Jul 20, 2017 at 10:12:45AM -0400, Larry Blunk wrote:
> > > > >
> > > > >
> > > > >   We have ping tests scheduled between our nodes and noticed that
> > > > > the latency graphs do not show the results when selecting the 1-day and
> > > > > 3-day views.  1-week and longer views work fine.   The owamp latency
> > > > > results do not have any issues.    There are also issues
> > > > > on our perfsonar 3.5 boxes.  The 3-day graph view only shows the first
> > > > > 24 hours
> > > > > of ping latency, and then cuts out.
> > > > >
> > > > > -Larry Blunk
> > > > >  Merit
> > > > >
> > > >
> > > > --
> > > > Michael Johnson
> > > > GlobalNOC Software Engineering
> > > > Indiana University
> > > > 
> >
> > > > 812-856-2771
> > > >
> > >
> > >
> > >
> > > --
> >
> >
> >
> > --
> > Michael Johnson
> > GlobalNOC Software Engineering
> > Indiana University
> >
> > 812-856-2771
>
>
>
> --



--
Michael Johnson
GlobalNOC Software Engineering
Indiana University

812-856-2771