>>> On 10/31/2007 at 4:53 PM, in message <[EMAIL PROTECTED]>, "Bernard Li" <[EMAIL PROTECTED]> wrote: > Hi Brad: > > Good job in compiling the list! > > I would like to complete my updates to the spec file before you do any > massive check-ins (or modifications to the spec file). So as a group, > can we answer the following questions: > > 1) Do we want to allow multiple versions of libganglia to be installed > on the same server
Yes, not because I see a real need for it now, but it might come back to bite us later if we don't. > 2) All versions of libganglia 3.1.x (eg.) should be compatible with > each other, i.e. 3.1.0 is compatible with 3.1.1 but not 3.2.x Yes, we have to provide for some level of version stability but at the same time allow for innovation. > 3) Do we want to name libganglia package like libganglia_3_1-3.1.0 > according to Novell's packaging rules Since Novell is my employer, sure ;) But do what is best for the project. > 4) Split python related DSO modules to ganglia-gmond-python -- and > hopefully in the future we'll have ganglia-gmond-perl Even though I have argued before that the python interface should be included in the gmond package, I think I have changed by position. If there is a real chance that a perl interface will be built (and I would love to see it happen), then we should set the precedence now for separate language packages. Although what might end up happening is that users will install all language packages anyway because not all metrics modules will be available for all languages. But at least that gives the user the option rather than it being forced on them. Brad > On 10/31/07, Brad Nicholes <[EMAIL PROTECTED]> wrote: >> I took a quick look over the wish-list items that were proposed on the > mailing list and tried to determine which items would break compatibility and > therefore must be completed before we release 3.1.0. I have identified three > tasks for which I am planning on completing and commiting the code to trunk > over the next few weeks. These tasks include: >> >> 1-* Add TITLE attribute to the XDR data to communicate a human readable name >> There is another task on the wish list which makes this more general > which is: >> -* Flexible method of adding extra metric metadata. >> We could include extra metadata, not just "alias"/"title". For > example, some >> metrics have a natural minimum and maximum value. Perhaps coming up > with an >> extendable way of encoding metric metadata so future changes can be > included >> without losing backward compatibility. >> I would rather implement the more flexible method of adding extra metric > metadata but I am not really sure how to do that with XDR. If somebody has a > good idea of how that could be done with XDR, please let me know. Otherwise > I will probably just add the attribute to the existing set of attributes. >> >> 2-* Add a GROUP attribute (comma delimited) to the XDR data >> This would allow metrics to declare the category that they belong to. > The category should be added at the metric definition level within the metric > module rather than a directive in the .conf file. Again if there were a more > flexible way to add extra metric metadata to the XDR package, that would be > the preferred method. Short of that, I just plan to add an attribute that > would hold a comma delimited list of group names that a metric can belong to. >> >> 3-* Modify all byte count metric to 8 byte integers >> At this point I am assuming that this is one of the issues that is > causing the 4T limit problem. For now this is just a temporary fix. The > real fix would be to move all of the built in metrics out of gmond itself and > implement them as C interface modules which define the correct counter size. > If somebody wants to tackle porting the built in metrics rather than applying > the temporary fix now, please feel free and let me know that you are doing > it. Otherwise, I will try to take care of at least getting the sizing right > and then port the metrics sometime later. >> >> >> I have attached a rough compilation of the tasks that were identified > through the wish list. This list is not very detailed and should probably be > used as a jumping off point for adding all of these enhancements into > bugzilla. Once in bugzilla, more detail should be added to each enhancement > so that we can have a good discussion about each one, prioritize them and get > them implemented. >> >> Brad >> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
