On 22/08/12 18:40, Alex Dean wrote: > Putting a UUID in a field called 'HOST' seems backwards-incompatible to me. > You're changing the meaning of the HOST field, even if the data type remains > the same.
Just to clarify, this is the way it works on the branch: that doesn't mean it is the best way of doing it. The branch is there to experiment with the UUID concept and find the best solution for everybody. I won't merge the branch into trunk until there is some consensus about it Nonetheless, it ONLY puts the UUID in there if you have some other nodes sending UUID packets. If you don't enable UUID sending, you would never encounter this. > I'd favor reserving 'HOST' for a hostname, and adding a 'UUID' field to the > XML for UUIDs. Technically, a new attribute is better: but just remember, some people may be parsing the XML with other tools, and they might choke on a new, unknown attribute. There is no solution that pleases everybody. > On Aug 22, 2012, at 10:02 AM, Daniel Pocock wrote: > >> Actually, there will be an option for that in gmond.conf, so it can be >> deployed in either of two ways, depending upon what is needed by the admin: >> >> a) put UUID in HOST/@NAME (so that XML schema does not change) >> >> b) put UUID in some new attribute > > Making this configurable seems like unnecessary complexity. Wouldn't the web > UI then have to know which mode gmond is running in (and support either), or > would gmetad normalize this somehow? gmetad doesn't really seem to care, it just sees the hostname or UUID as a string I didn't have to patch my gmetad or web at all to use this. I only patched gmond itself and the whole thing seems to work. gmetad created the directory cluster/UUID/*.rrd right away ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
