Dear all:
If you build RPMs from the tarball and try to upgrade, RPM will create
/etc/ganglia/{gmetad,gmond}.conf.rpmsave. This is because there were
modifications made to the configuration files from the previous
version.
For gmetad, the modifications are negligible, so you can keep your old
configuration. For gmond, the modifications are also pretty much
negligible, but there are noticeable differences (mostly the moduledir
is auto-detected so the full path is no longer necessary). If you
would like to use the new base configuration file, do the following:
1) Before you upgrade, run `gmond -t > ~/gmond-3.1.0.conf`
2) `diff -ru gmond-3.1.0.conf /etc/ganglia/gmond.conf > ~/gmond.conf.diff`
3) `mv /etc/ganglia/gmond.conf /etc/ganglia/gmond.conf.bak`
4) `mv /etc/ganglia/gmond.conf.rpmsave /etc/ganglia/gmond.conf`
5) `cd /etc/ganglia/ && patch -p0 --dry-run < ~/gmond.conf.diff`
6) If everything checks out, run patch without the '--dry-run' option
7) You're done
We look forward to hearing your experience and issues you might have
with the upgrade to Ganglia 3.1.x!
Thanks,
Bernard
On Mon, Aug 18, 2008 at 8:46 AM, Carlo Marcelo Arenas Belon
<[EMAIL PROTECTED]> wrote:
> Greetings,
>
> So it is finally here, the release date for testing of ganglia 3.1.1 and to
> keep up with traditions, everyone that can do an official package is
> unavailable so we are again stuck with my unofficial one, which you will
> have to take my word on that, is pretty much the same than the original
> package will be as it has been even bootstrapped with the same obsolete
> autotools we use for official releases, but has an incorrect release name, as
> we all hope it will have a better name than the current hack on the previous
> one.
>
> In any case, this package should be good enough for getting some testing going
> so we are ready with our build scripts and packages from when the official
> pre-release package comes in a couple of days and is immediately available
> from:
>
> http://tapir.sajinet.com.pe/ganglia/ganglia-3.1.1.tar.gz
>
> The list of features/bugfixes included in this release are:
>
> * Fix segfault when aggregating 3.1 gmetad
> * Fix failures and instability for tcpconn.py
> * Module directory configurable at build and run time
> * Autodetect libdir/moduledir for bi-arch Linux architectures
> * Include contrib directory with user provided goodies
> * Support for building C++ DSO
> * Support for building with Sun Studio 12 in OpenSolaris
> * In node view show correctly the downtime relatively to cluster time
> * In meta view show grid summary always on top regardless of sorting
> * Add "Avg Load percentages and overall cluster utilization"
> * Bug fixes and Enhancements
>
> Which basically means it should work better than 3.1.0 did in almost any way
> possible and has removed some annoying bugs that were released with 3.1.0 and
> that were affecting you, our dear early deployers.
>
> Don't get confused though, as this is no small release either with up to 2639
> lines of code changed overall and so testing it to confirm it will work well
> when released in your environment is encouraged by following and coming back
> to us hopefully with good news from the following questionnaire:
>
> * which platform are you testing it on (OS name and version), which
> architecture (CPU type and bitness), do you have binary packages provided
> to use, do they work?
> * does the ganglia package build from source in your platform? does also
> gmetad? does it provide for loadable modules and static builds or only
> static builds? does it build python module support? any warnings reported
> when building it?
> * after building it, does gmond -m provide a list of available modules?
> * if python module support was enabled, can a simple python module be loaded
> and used? does tcpconn.py work stable?
> * if upgrading from an older version of ganglia (not including 3.1.0) does
> the
> configuration converter (for 2.5) or manual update (for 3.0) produce an
> equivalent working configuration?
> * if able to update (or setup for testing) two or more gmond are they able to
> work together and report valid metrics for a cluster?, do they work OK
> using multicast, unicast or both.
> * can your new 3.1.1 gmetad be configured to pull data from your existing
> environment without problems or misreporting metrics when compared with
> your
> current gmetad?
> * can you use 3.1.1 in a hierarchical gmetad configuration with your
> current gmetad?, if able to upgrade (or setup for testing) two 3.1.1 gmetad
> can they be configured in a hierarchical gmetad configuration?
> * do gmond or gmetad work reliably (not crashing or needing a restart) during
> the test window, is the memory utilization stable and CPU load under the
> expected values when compared with your current production environment?
> * is there anything else you had found during your test cycle that you would
> like to be addressed?, is it something that worked before and doesn't now
> (a regression)?
>
> Some of the most visible changes I can come out with from the top of my head
> and that we should be specially looking for regressions as compared with 3.1.0
> are:
>
> * This gmetad could be finally used as a complete replacement for 3.0 gmetad
> even if you are using a hierarchical setup and without segfaulting. Some
> other misconfigurations that used to segfault gmond are now also handled
> better too and if you still have some of those that are not reported already
> in our release_notes then please let us know about them.
> * All those delays and tracebacks when using tcpconn.py are gone and if you
> find more we will take them more seriously next time.
> * There are several user contributed scripts/addons/tools in the contrib
> directory which you might find useful for your setup.
> * In some platforms (BSD) where /var/lib/ganglia doesn't exist for storing
> the RRDs they will be now by default stored and used from /var/db/ganglia
> (still if you are running gmetad, you should probably do it in Linux anyway)
> * If you are using a linux distribution with bi-arch support (like 32/64 bit
> x86 or ppc) where the library directory is different than /usr/lib and
> building your packages from source, all modules should magically go to
> the right directory now. If you want to force all modules to go to a
> different place there is a --with-moduledir configure option you can use
> and there is also a "moduledir" global configuration you could use to
> override that at runtime. One interesting sideffect of it all is that
> now a generated configuration wouldn't have by default all those ugly
> hardcoded paths for each DSO but you can still use them if you want.
> * the web frontend navigation should be smoother, avoiding those white pages
> reloads when selecting a grid from the list; remembering the metric name
> you selected when browsing around; not moving the grid summary around if
> you select to sort your grids in meta view; reporting a clear message when
> a host is down in the shownode page so you know for how long it has
> been down and even showing that missing "Grid" in the title for all those
> grids you have in the "Grid View" and that I am sure was driving you nuts.
>
> Carlo
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Ganglia-developers mailing list
> Ganglia-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ganglia-developers
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
