Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] GEANT2 RRD^H^H^Hutilization MA down; perfsonarUI feedback

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] GEANT2 RRD^H^H^Hutilization MA down; perfsonarUI feedback


Chronological Thread 
  • From: "Vedrin Jeliazkov" <>
  • To: Simon Leinen <>
  • Cc: <>
  • Subject: Re: [perfsonar-user] GEANT2 RRD^H^H^Hutilization MA down; perfsonarUI feedback
  • Date: Tue, 24 Oct 2006 19:30:32 +0300
  • Disposition-notification-to: "Vedrin Jeliazkov" <>

Hi Simon,

Many thanks for your comments. Please have a look for some answers and further
comments inline.

Simon Leinen
<>
wrote:

> [Is there a more suitable place for such inquiries?]
>
> I just tried to show the perfsonarUI client to a fellow PERT member
> here, but we noticed that the GEANT2 RRD (link utilization) MA doesn't
> seem to be up. This is corroborated by the Smokeping graphs:
>
> http://netmon.acad.bg/smokeping?target=svc.prfs.RRDS.GEANT

The tomcat server, hosting GEANT2's RRD MA seems to be down since late Friday
evening. Automatic alerts have been sent to the maintainers. Meanwhile you
could try some of the remaining RRD MA services.

> My colleague also had a few interesting remarks about the perfsonarUI
> interface. His first question was
>
> * Why isn't this application available on a Web page?
> (running on the server side in a servlet or something)

The next release of perfsonarUI will be made available via Java Web Start in
parallel to the *.exe and *.zip distributions. Hopefully this would provide
the functionality you're asking for.

The centralized solution introduces a single point of failure (server down or
unreachable) and that's why we've chosen to produce a standalone application,
which could take advantage of the very distributed architecture of perfSONAR.
However, we agree that the centralized solution might complement quite well
the standalone application in some cases.

> A few other observations:
>
> * It is still somewhat too hard to get a running perfsonarUI client,
> even if one already has a suitable Java runtime environment: The
> MA.conf file in the perfsonarUI package distribution (.zip) has to
> be replaced by a newer MA.conf which can be found on the JRA1 Wiki
> *if* you look very hard. In addition, although the caption (anchor)
> of that file says "MA.conf", the URL ends in "MAs.conf", so you have
> to rename it for installation (please don't tell me that this is
> done on purpose "for safety" :-).

The presence of the "s" in MAs.conf is due to the fact that the wiki wouldn't
allow an upload of a file with a name containing less than 3 symbols in front
of the dot. Moreover, MA.conf is only a temporary workaround, while the
perfSONAR Lookup Service becomes available and all deployed services are
upgraded to support the latest schema.

> Note that this would be much easier if the application was
> implemented as a Web page - the MA.conf and Hades.conf files could
> then be centrally managed.

The above mentioned JWS version of perfsonarUI will not need MA.conf - it will
be maintained on a regular basis to include an up-to-date list of deployed
services.

As of Hades.conf - we have already implemented a mechanism for discovering the
available measurements in the Hades MA through exchange of perfSONAR messages,
so this config file would become obsolete quite soon, when the next version of
perfsonarUI is released.

> * Data retrieval takes a very long time, especially if you don't
> deactivate irrelevant or non-functional MA servers beforehand.

Response time is definitely an issue. Some optimisations have been already
implemented both on the client and server side and will become available in
the next official releases.

> (Wouldn't it be nice if this were done automatically?

Discovery of non-functional MA servers is on our TODO list (F09):

http://wiki.perfsonar.net/jra1-wiki/index.php/PerfsonarUI#TO_DO

It might be a good idea to automatically disable queries to non-functional
services as a temporary workaround. However, when the perfSONAR Lookup Service
becomes available, this workaround would become obsolete and that's why it
isn't placed high on our priority list.

Discovery of "relevant" services for a particular query is a more
sophisticated task, which might be solved by the planned introduction of
topology service.

> And does
> anyone else find "Endpoints" counter-intuitive as a name for the
> interface that allows me to select/unselect measurement servers?)

The GUI will be entirely revamped in the next release of perfsonarUI,
according to the user feedback and as described in the TODO list. Could you
suggest a more suitable name for this control?

Best regards,
Vedrin
--
-----------------------------------------------------------------
* * Vedrin JELIAZKOV - Network Engineer
* * Institute for Parallel Processing
* IST Foundation * Bulgarian Academy of Sciences
* The Bulgarian NREN * Acad. G. Bonchev St 25-A
* * 1113 Sofia, Bulgaria
* * Tel: +3592 9796606
http://www.ist.bg ICQ: 42633308
-----------------------------------------------------------------
PGP Public Key
http://cert.acad.bg/pgp-keys/keys/vedrin-jeliazkov-0x0F7EF249.asc
7EA1 7539 9B83 D8BF 4C1D 4890 0CE5 0B4B 0F7E F249
-----------------------------------------------------------------





Archive powered by MHonArc 2.6.16.

Top of Page