[Gluster-devel] gluster layout proposal - rev2

Anand Avati avati at hardcodecafe.com
Sat Apr 9 07:44:14 UTC 2005


i evaluated layouts of debian, slackware and netbsd. 
our layout is similar to that of slackware, with small
tinges of netbsd layout.

gluster source base is spread across CVS and FTP..

CVS - contains the 'clustering logic' .. informally this is the python
source codes.. this is where the active development of gluster happens.
this contains gluster-core, gluster-ext, gluster-apps (all python)
see http://hardcodecafe.com/~avati/src/gluster/cvs_co_sample for how things
should be in the CVS. (This is hereafter referred as 'gluster-cvs')

FTP - contains necessary stuff to make gluster LIVE. this includes
kernel,libc,python,busybox,dhcpd,inetd,busybox etc..
see http://hardcodecafe.com/~avati/src/gluster/ for how things should be
in the FTP server. (This is hereafter referred as 'gluster-live') [Note:
cvs_co_sample/ there will be removed]

FTP maintainance:
Development noise in the FTP is less. commits/changes are sparse and rare.
In general, work in the ftp goes on like this: All work happens in
gluster-current direcotry. New versions of packages are added here,
installation scripts are improved here. Once we have a stable FTP
gluster-current tree, development work here will be very little. 

   Since FTP does not favor parallel development, and since the noise here
is anyway less, we can have one person be the 'gluster-live maintainer'.
All new packages/ install/build script updates should be streamlined by
sending to the maintainer, and NOT upload the changes oursleves.

Versioning: 

The principal behind the FTP tree is "build a live image out of package
sources". For this, gluster-cvs itself is just another package like inetd.
gluster-cvs versioning CAN be seperate from gluster-live release 
versioning, but we shall keep them in sync. For eg. inetd version can
keep upgrading in the gluster-current, but we dont do a new release of
gluster-live for a new version of inetd. similarly gluster-cvs version
is independant of gluster-live version, but as a thumb rule, to avoid
confusion, we keep them in sync, i.e for every new release of
gluster-cvs, we do a release of gluster-live with the same version
number.

Releasing process:

A snapshot of gluter-current is copied into gluster-$VER for $VER
release. Inside gluster-$VER, an automation script is run which tarballs
the source direcotry into a single tarball. Each 'Arch' maintainer takes
the tarball, 'extrand-and-build.sh' with the tarball, and releases the 'dist
tarball' and of-the-shelf-usable ISO image inside gluster-$VER/$ARCH.
There is NO ISO or DIST for gluter-current.
A top level symlink 'gluster-latest' points to the latest release
directory for easy of search for downloads.


Building completely from source:

For Mr.Average, gluster-$VER/$ARCH/gluster-$VER-$ARCH.iso is all what he
needs. for Mr.Hacker who wants to compile _everything_ from sources,
here is the procedure.


wget -r http://../gluster-current/sources
cd gluster-current/sources
./extract-and-build.sh

gluster-current/sources contains a daily cvs snapshot which will be used
in the above step.

NOTE: cvs co of gluster-cvs and make/make install will result in 'NATIVE
MODE INSTALL'. for a LIVE image, the above step should be followed

This is a top-level view of how things work. Finer details of script
names, directory structure within source/ $ARCH/ are to be discussed
after a feedback for this document.

feedback please
regards,
avati

-- 
Once upon a time there was a DOS user who saw Unix, and saw that it was
good.  After typing cp on his DOS machine at home, he downloaded GNU's
unix tools ported to DOS and installed them.  He rm'd, cp'd, and mv'd
happily for many days, and upon finding elvis, he vi'd and was happy.  After
a long day at work (on a Unix box) he came home, started editing a file,
and couldn't figure out why he couldn't suspend vi (w/ ctrl-z) to do
a compile.





More information about the Gluster-devel mailing list