Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
On Tue, Jan 05, 2010 at 02:42:28PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Mon, Dec 28, 2009 at 10:51:51PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote: Ok, but if it is not locked down, let's consider some of the following: - document the version we expect agree, and that is what README.SVN is for, but first we have to decide which version to expect to begin with. guess that if we are going to use lenny then the defaults for that distribution should be documented then as a prerequisite here since anything older won't be tested anyway? automake: 1.10 (1.10.1) autoconf: 2.61 libtool: 1.5 (1.5.26) while the last official release (3.1.2) used instead : automake: 1.9 (1.9.6) autoconf: 2.59 libtool: 1.5 (1.5.22) and the de-facto standard (CentOS 4) used instead : automake: 1.9 (1.9.2) autoconf: 2.69 libtool: 1.5 (1.5.6) - maybe add some check to configure that warns if a different version of autotools is detected? configure doesn't depend autotools and so that would be the wrong place to put any checks, but configure.in does and there is where bootstrapping should be aborted using AC_PREREQ and friends if using the wrong versions. Ok, should we use AC_PREREQ for 3.1.6, are there any disadvantages? only if the macros will definitely break with an older version of autoconf as otherwise all we are doing is enforcing a recommendation and preventing anyone that might not have access to the newest version of autotools the posibility of getting their own bootstrap (not much of an issue if we also provide regular snapshots though). I've had a quick search for information on this - it appears that adding AC_PREREQ(2.61) would cause bootstrapping to fail on any older or newer version - only 2.61 would be supported. will fail if any older version is used, but work also for newer versions I think this is the right way to go, as it will prevent us from running in to the same issues again, and it will hopefully prevent people building trunk with a different version of autotools and creating bugs that no one else can re-produce. not really, all we are doing is preventing some developer to generate their own bootstrap of ganglia if they have only access to an older than 2.61 version of autoconf, even if it is very likely that 2.53 or older will be all that is really needed. if we are not providing periodic snapshots, then that developer won't be able to do any of the work he wanted to do, unless he upgrades his tools locally or gets a handle of another system where he can get a bootstrap (most likely installing debian 5 somewhere) and so we just made his life more difficult and probably even discourage him to scratch that itch. bootstrapping, doesn't mean releasing and so would expect release managers to use the versions or environment we know works, but that is something that can be done through process and documentation better than it can be done by code, hence why I suggest r2174 gets reverted. I think Debian 5.0 (lenny) is the final decision then Debian 5.0 (lenny) x86 (32-bit) right? I'm using lenny amd64 (64 bit) most of the time now, especially since the various browser plugins (e.g. Java) now support 64 bit Linux. the problems with the bootstrap of 3.1.2 might had been because of using a 64 bit bootstrap (as that was never seen when doing CentOS 4 x86), but if Debian 5 doesn't have that problem (we would have to confirm that the packages generated in x86 and amd64 are identical) then saying Debian 5.0 (lenny) should be enough to describe the suggested bootstrap environment. any final objections/comments? the only one I can think of is that we sometimes used to provide RPMs with the releases but that would be IMHO not that important considering that fedora/EPEL might be the package most people would use anyway and at least for fedora that used to be released fairly quickly after the source package was posted on our site as the fedora packagers are also actively involved in the list. Providing RPMs is probably much less important than having a stable bootstrap environment agree However, it would be good for packaging activities to continue, and I can't see why we can't script the release process so that it invokes the rpmbuild commands on a Fedora box over ssh. then you are going to need either 2 public resources for all release managers to use consistently or a coordinate release process were the package is generated and then independently binary packages are added to it before the announcement (which also means we have to agree on what is going to be used for building those RPM packages). Should we a) after fixing the other showstopper (fork issue), do we tag 3.1.6 and let people test a tarball from Debian 5 autotools?, or b) make another 3.1.5 tarball
Re: [Ganglia-developers] bind and bind_hostname parameters in udp_send_channel
after adding some basic documentation to trunk in r2122 and using them had found that the interface should be better improved before it gets released by either : * remove bind_hostname and overload that functionality on bind by defining a magic value which means (resolve default hostname) like . I also thought overloading might be good, but that could make it harder to read for someone unfamiliar with the file format We could overload on interface name or something too. I was thinking it could be done with a special character, e.g. if the hostname starts with @, it would be interpreted as an interface name rather than a hostname/IP address. However, the same thing could be done by adding a bind_dev parameter. * keep bind_hostname but converted into a boolean so it can be set like all other flags in gmond.conf and better handle what to do when both parameters are provided (currently bind_hostname seems to silently override bind) I prefer keeping it, although it can be deprecated later if an over-ride solution is adopted perhaps. I could make it mutually exclusive with bind, it should probably abort if it finds both options, but it may be sufficient to just log a warning. PS. backporting the documentation to 3.1 should be done also once it is stabilized I agree - I will do that I didn't mean to ignore this feedback - I had just left it there to see if other people had ideas on the subject before adding my own opinions. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] bootstrapping for 3.1.X series and 3.2.X
Carlo Marcelo Arenas Belon wrote: On Tue, Jan 05, 2010 at 02:42:28PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Mon, Dec 28, 2009 at 10:51:51PM +, Daniel Pocock wrote: Carlo Marcelo Arenas Belon wrote: On Sun, Dec 06, 2009 at 09:28:04AM +, Daniel Pocock wrote: Ok, but if it is not locked down, let's consider some of the following: - document the version we expect agree, and that is what README.SVN is for, but first we have to decide which version to expect to begin with. guess that if we are going to use lenny then the defaults for that distribution should be documented then as a prerequisite here since anything older won't be tested anyway? automake: 1.10 (1.10.1) autoconf: 2.61 libtool: 1.5 (1.5.26) while the last official release (3.1.2) used instead : automake: 1.9 (1.9.6) autoconf: 2.59 libtool: 1.5 (1.5.22) and the de-facto standard (CentOS 4) used instead : automake: 1.9 (1.9.2) autoconf: 2.69 libtool: 1.5 (1.5.6) - maybe add some check to configure that warns if a different version of autotools is detected? configure doesn't depend autotools and so that would be the wrong place to put any checks, but configure.in does and there is where bootstrapping should be aborted using AC_PREREQ and friends if using the wrong versions. Ok, should we use AC_PREREQ for 3.1.6, are there any disadvantages? only if the macros will definitely break with an older version of autoconf as otherwise all we are doing is enforcing a recommendation and preventing anyone that might not have access to the newest version of autotools the posibility of getting their own bootstrap (not much of an issue if we also provide regular snapshots though). I've had a quick search for information on this - it appears that adding AC_PREREQ(2.61) would cause bootstrapping to fail on any older or newer version - only 2.61 would be supported. will fail if any older version is used, but work also for newer versions I think this is the right way to go, as it will prevent us from running in to the same issues again, and it will hopefully prevent people building trunk with a different version of autotools and creating bugs that no one else can re-produce. not really, all we are doing is preventing some developer to generate their own bootstrap of ganglia if they have only access to an older than 2.61 version of autoconf, even if it is very likely that 2.53 or older will be all that is really needed. if we are not providing periodic snapshots, then that developer won't be able to do any of the work he wanted to do, unless he upgrades his tools locally or gets a handle of another system where he can get a bootstrap (most likely installing debian 5 somewhere) and so we just made his life more difficult and probably even discourage him to scratch that itch. bootstrapping, doesn't mean releasing and so would expect release managers to use the versions or environment we know works, but that is something that can be done through process and documentation better than it can be done by code, hence why I suggest r2174 gets reverted. Those are good points - but while it may be easier for people to get started developing if we are not strict about this, it means they could end up committing stuff that doesn't work when bootstrapped for release. Some ideas: - should we consider using AC_PREREQ on the release branch, but not on trunk? - should we add some over-ride option to the bootstrap script? Then the developer who understands the issues has a shortcut - should we add some errors to the bootstrap script, so that if it fails, it gives verbose output suggesting the user read this thread, remove AC_PREREQ, update autotools, etc I think Debian 5.0 (lenny) is the final decision then Debian 5.0 (lenny) x86 (32-bit) right? I'm using lenny amd64 (64 bit) most of the time now, especially since the various browser plugins (e.g. Java) now support 64 bit Linux. the problems with the bootstrap of 3.1.2 might had been because of using a 64 bit bootstrap (as that was never seen when doing CentOS 4 x86), but if Debian 5 doesn't have that problem (we would have to confirm that the packages generated in x86 and amd64 are identical) then saying Debian 5.0 (lenny) should be enough to describe the suggested bootstrap environment. Can you conveniently test that? any final objections/comments? the only one I can think of is that we sometimes used to provide RPMs with the releases but that would be IMHO not that important considering that fedora/EPEL might be the package most people would use anyway and at least for fedora that used to be released fairly quickly after the source package was posted on our
[Ganglia-developers] rrdcached support for 3.1.6
I've backported the rrdcached support to monitor-core-3.1 branch Any feedback is welcome - it is an optional feature, disabled by default - I've been running it successfully - it has been in trunk for a while -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
[Ganglia-developers] multicpu module: r2116 and other issues
I've been contemplating the multicpu module, which currently only works on Linux and Cygwin. Carlo has indicated that promoting it's use (as a consequence of the PCRE patch) may not be ideal for two reasons: a) bugs on the supported platforms (Linux and Cygwin) b) not functional on other platforms (e.g. Solaris) where it gives no meaningful error if a user tries to load it For the Solaris platform, I was considering the idea of a generic kstat module. It would generate thousands of metric names (gmond -m output), but CPU metrics could then be selectively enabled with the PCRE support. So a dedicated multicpu module for Solaris may not be needed. I don't think it is necessary for every module to run on every platform - maybe this one just shouldn't be compiled at all except on Linux and Cygwin. Maybe it is also possible to consider some other options: a) mark some modules as experimental/beta, and have a single configure option for enabling all experimental modules, a separate package for them, etc b) split the development of some modules from the monitor-core-3.1 branch so that they don't hold back releases -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
