Markus, your envionment certainly sounds like it is under control, but in mine, the engineered Linux build has packages that in some instances are really quite old. Old enough for the Ganglia build to barf.
In some cases a fix would have been easy because the package was not there at all. And because I control the Ganglia servers they were not too much trouble with them anyway. But we are an investment bank. Some of our monitored hosts are related to trading, pricing, and quants (HPC for risk etc). If the ganglia agent is provably self contained, placing it on these system is OK. But if we wanted to upgrade a 3rd party package we would need to ensure the packages/libraries were not used by the apps teams, and if they were, go through a build, test, release cycle for the app code. work work work. So while I head what you say, I prefer static (Or dynamic but using the copies of the 3rd party libraries stored in the ganglia tree). kind regards, Richard > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Marcus Rueckert > Sent: 03 September 2006 14:57 > To: matt massie > Cc: [email protected] > Subject: Re: [Ganglia-developers] 3.0.4 and srclib > > > On 2006-09-03 00:36:29 -0700, matt massie wrote: > > i wanted to comment on the who "srclib" library business. > there are > > two separate issues that need to be addressed. > > > > first. > > > > i feel it is critically important that gmond be statically linked > > against all support libraries. there are sysadmins our > there managing > > 1000s of ganglia machines and having a single statically > linked binary > > makes it easy for them. imagine needing to do a yum update on > > thousands of hosts in order to make sure all rpm > dependencies are met on upgrade. > > ouch. imagine using an os without a package manager and managing > > library dependencies. ooouch. > > it is not this worse. people do that all the time. and where > is the problem of installing 3 packages instead of 1? most > likely they have installed a few other packages already anyway. > > > second. > > > > i don't really care one way or another how the source for > the support > > libraries gets on the _compile_ host since we will statically link > > against those libraries anyway. having them in the > "srclib" directory > > gives us more control and makes it easier for people to > download and > > compile. although it also makes packaging and maintenance for us a > > lot harder. > > statically linking stuff is a maintenance nightmare. > anyway it should be optionally possible to dynamically link. > > The idea is to improve the package coverage of ganglia, so > you dont have the need of pushing around statically compiled > versions. And nothing stops packages from providing the > statically linked binary. Statically linked against the > libraries shipped with the distro of course. > > darix > > -- > openSUSE - SUSE Linux is my linux > openSUSE is good for you > www.opensuse.org > > -------------------------------------------------------------- > ----------- > Using Tomcat but need to do more? Need to support web > services, security? Get stuff done quickly with > pre-integrated technology to make your job easier Download > IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&; dat=121642 _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------
