On Friday, March 14, 2003, at 08:47 AM, Jason A. Smith wrote:

I am seeing two major problems:

First, what exactly is the purpose of the new GRID tag?  It seems that
it is a mandatory part of the new gmetad system, and more importantly
the authority attribute is mandatory. Is this correct? It appears that
if you setup one gmetad to collect data from another gmetad that adds
this grid tag and authority attribute, then the second gmetad only
writes summary rrds, correct?

Yes.

This is a problem for us because of the
way we had and would like to continue using ganglia at our computer
facility.  We would like to have an internal ganglia monitoring host to
monitor our whole facility which spans 5 separate experiment clusters.
Then allow the individual experiments to get the xml data from our
gmetad collector and reproduce it on their own webserver without having
links redirect them to our main webfrontend.
They might also be adding
in clusters from outside of BNL that are part of their experiment.  Our
main facility gmetad would monitor everything, but its webfrontend would
not be visible outside of the BNL firewall, so passing around the
authority attribute would not work and should be optional.  I would
suggest having the ability to turn this new authority option off.  If
the authority is there then gmetad should assume that it can redirect
you there to find the rrd graphs, but if it is off then the second
gmetad that polls it should reproduce all of the rrds locally.  Does
this make sense and sound reasonable?

You want a simple XML aggregator. Yes, it is reasonable to have an option that turns off the Grid functionality (GRID tags and authority attributes).

Alternatively, you could replicate the "data_sources" on each experimental (outside) gmetad, so each of these queries the gmond of your five clusters directly. Not quite as nice as your solution, I know - permissions are a pain. Also, it would be fairly easy to write a simple XML aggregator in a high level language like Python/Perl. But having a "old-style operation" switch is definitely reasonable.

Federico

Rocks Cluster Group, SDSC, San Diego
GPG Fingerprint: 3C5E 47E7 BDF8 C14E ED92  92BB BA86 B2E6 0390 8845


Reply via email to