----- Original Message ---- > From: Bernard Li <[EMAIL PROTECTED]> > To: Brad Nicholes <[EMAIL PROTECTED]> > Cc: [email protected] > Sent: Wednesday, October 31, 2007 11:53:46 PM > Subject: Re: [Ganglia-developers] Moving on with Ganglia 3.1... > > 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. > 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 I am not sure. What happens if we have to fix a severe bug in 3.1.X+1 that involves changeing some of the APIs exposed by libganglia-3.1.X? Would that forced us to do a 3.2.0 release? But it would definitely be *desirable* that version 3.1.X can use libganglia version 3.1.X+ > 3) Do we want to name libganglia package like libganglia_3_1-3.1.0 > according to Novell's packaging rules I have no opinion on this one > 4) Split python related DSO modules to ganglia-gmond-python -- and > hopefully in the future we'll have ganglia-gmond-perl > I am not sure whether a language split is needed or useful. Implementation languages are all the same for me. What I would do is split along the lines of basic-framework vs. core-modules vs. special-modules. Cheers Martin > Let's try to wrap this up within the week, thanks all! > > Cheers, > > Bernard > > On 10/31/07, Brad Nicholes 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/ganglia-developers > > > > > > > > ------------------------------------------------------------------------- > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/ganglia-developers > > ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
