On Fri, 2004-09-17 at 03:27, Martin Knoblauch wrote: > Hi Matt, > > --- Matt Massie <[EMAIL PROTECTED]> wrote: > > > i just uploaded a new snapshot/demo to > > http://matt-massie.com/ganglia/ > > > > would you consider putting timestamps into your tarballs and rootdirs? > All the 2.6.0 tarballs are getting a bit confusing.
i just updated the configure.in and makefile.am scripts to automagically
generate snapshot tarballs on demand. automake also generates the
distibution in multiple archive formats (bzip2, zip, etc) automatically.
the version name of a snapshot is MAJOR.MINOR.MICRO.YEARMONTHDAY . the
files inside are also extracted into a directory with the same name. in
short, there should be no more confusion about what snapshot you
actually are working with.
if someone has the time to volunteer.. in the near future i'd like to
get these snapshots off my web server and on to sourceforge. i haven't
in the past because of the hassle involved (the sf gui is rough).
> On Suse 9.1 I had to add "-lz" to the "gangliad" link line. Otherwise
> it would complain about "z_errmsg" at startup.
thanks for the feedback. i just added a check for the zlib library in
configure.in from now on "-lz" should be appended to LIBS.
> > For one, before I begin, I want to say that we are not going to use
> > POSIX threads given the horrible shape of threads on Linux. Brent
> > (the author of gexec) and I have had nightmares tracking down that Linux
> > kernel threads do not support necessary thread cancellation points.
> > It's ugly. Instead, gangliad uses GNU portable threads (look in the
> > ./srclib/ directory).
> >
>
> sounds like a reasonable choice.
to be completely honest... POSIX thread nightmares have really hurt
ganglia development a lot. very very frustrating. i wish the kernel
developers and/or package maintainers would have used a "opt-in"
strategy for the new awesomely fast and poorly implemented kernel
threads... instead being "opt-out".
> - this looks like a cool new concept. And definitely a revolutionary
> and not evolutionary step towards the next-gen Ganglia. From a
> developers point of view I love it. The question is - is this not worth
> a bump in the major number?
i was thinking that too. i think this will be a 3.0.0 release.
in regard to the versioning. if you look in the top of configure.in,
you'll see a nice section for making sure we do the library versioning
correctly (which is important given we are creating a shared library).
one product of the version scheme that the micro version will always
increment.
for example...
3.0.0
3.0.1
3.0.2
3.1.3
3.1.4
3.2.5
3.2.6
3.2.7
3.3.8
and so on. i know that federico has told me that he doesn't really like
it when he gets software at version 5.6.982.
any feedback on the versioning? does anyone have problems with the new
approach. btw, if you want a different versioning scheme than please
take the time to write the autoconf/automake magic to make it automatic
to implement.. or help someone else (me?) do it.
> - From my adminstrators view (and maybe my advanced age :-) I do not
> like lrevolutions. So the concerns from my side are:
>
> --> Compatibility to pre-2.6 Ganglia. Moving to the new framework will
> be difficult if to many things have to be changed. The GUIs should not
> change to much and we need to preserve the historical data.
i'm not exactly sure what you mean here. are you afraid that the
rrdtool databases from 2.5.x will not be compatible with the new
framework?
i will make a mod_ganglia25 and mod_ganglia25_xml to ensure as much
compatibility with old data sources.
> --> Continuation of the 2.5.x series with bug-fixes and [minimal] new
> features maybe necessary for the near future.
agreed. federico just checked in a new feature into the 2.5.6 branch
which prevents gmetad from leaking memory in certain circumstances.
> anyway, I am looking forward to seeing the new stuff in more action.
it's coming down the pipe.
i just put out a new snapshot where i took all the "filesystem"
functions out of ./lib/api.c and ./lib/protocol.c and put them in
./lib/filesystem.c. i will start today cleaning it up and making more
uniform. overall the structure will be like this
directory
|
+---- file
| |
| +---- contents
| 1. string
| 2. integer
| 3. double
| etc etc
|
+---- link
|
http redirect
each child in this tree is created from the memory pool of the parent it
is attached to... meaning a simple pool_free of a directory flushes all
files, data and symbolic links.
a link will be like a filesystem's symbolic link but will be implemented
with a HTTP redirect. this will replace our current AUTHORITY scheme.
if a host doesn't have the requested data but know where to get it... it
will redirect you to the correct host.
i have all the code to implement this.. i just need to shrub/test it.
-matt
--
PGP fingerprint 'A7C2 3C2F 8445 AD3C 135E F40B 242A 5984 ACBC 91D3'
They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.
--Benjamin Franklin, Historical Review of Pennsylvania, 1759
signature.asc
Description: This is a digitally signed message part
