Thanks for the pictures, they helped me visualize the problem. I agree with you, even in non-scalable mode, gmetad should output a GRID tag. I have made the change to server.c, and initial tests here look good.
I have committed the gmetad changes to CVS. No changes were made to the webfrontend. -federico On Thursday 11 September 2003 10:02, Jason A. Smith wrote: > I have a single computer running gmetad, collecting data from 10 > separate clusters. The webfrontend is running on that same computer, > like this: > > webfrontend --> gmetad (not scalable) --> 10 separate clusters > > I noticed the new scalable feature and tried it out when I saw the > problem. I have attached two webfrontend snapshots, the one called > scalable is the normal old view. If all I do is change the scalable > option to off and restart gmetad, I get the second picture, where you > can see that the total grid plots are now fourth from the top and don't > have the grid name there anymore. > > That is why I suggested that the GRID tag should always be present in > the xml output from gmetad, but ignore it on input, so the grid name is > always present, for the web-frontend and other gmetads to use if they > like. It is up to the higher level gmetad to decide if it will be > scalable or not and ignore the grid tag and its authority location. The > source gmetad can only offer the scalable option but the higher gmetad > can choose to ignore it and reproduce all rrds locally. Of course, it > would also be nice if the source gmetad could report its grid name for a > nicer tree layout, but somehow let the higher level gmetad know that it > is not available for authority referrals, maybe because of firewall or > other security issues. > > ~Jason > > On Wed, 2003-09-10 at 14:47, Federico Sacerdoti wrote: > > Could you take a screen snapshot and send it to me? > > > > Just so I understand, you have a setup something like this: > > > > gmeta (not scalable) ------> gmeta (not scalable) ----> cluster1
