Menu
▾
▴
ci-linux-devel — Discussion about Cluster Infrastructure for Linux
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(25) |
Jul
(13) |
Aug
(11) |
Sep
(14) |
Oct
(5) |
Nov
(7) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(14) |
Feb
(10) |
Mar
(30) |
Apr
(9) |
May
(20) |
Jun
(12) |
Jul
(7) |
Aug
(6) |
Sep
(6) |
Oct
(34) |
Nov
(14) |
Dec
(9) |
| 2003 |
Jan
|
Feb
(9) |
Mar
(2) |
Apr
(2) |
May
(5) |
Jun
(14) |
Jul
(1) |
Aug
(7) |
Sep
(6) |
Oct
(5) |
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(4) |
Oct
|
Nov
(7) |
Dec
(1) |
| 2005 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
(2) |
Jul
|
Aug
(5) |
Sep
(5) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Aneesh K. K.V <ane...@di...> - 2003-08-28 16:13:33
|
On Thu, 2003-08-28 at 17:28, Kumar, Aneesh wrote: > On Wed, 2003-08-27 at 20:17, Kumar, Aneesh wrote: > > Hi, > > > > I have packaged CI and openSSI for debian . The source (tar.gz ) and > > binary packages for same can be downloaded from > > > > http://openssi.org/contrib/debian/ > > > > > I have found some issues (mostly packaging error ) with the base > packages i uploaded yesterday. ( e2fsprogs/devfsd/ are having problems.) > I am working on this. I have deleted the uploaded packages as of now. > Will inform once i have it fixed. I have uploaded the new packages at http://openssi.org/contrib/debian/ BUG reports and patches are welcome. These packages are built on debian testing/unstable. I have done minimal testing with single node. That means the kernel boots and the base commands works. -aneesh |
|
From: Aneesh K. K.V <ane...@di...> - 2003-08-28 11:45:55
|
On Wed, 2003-08-27 at 20:17, Kumar, Aneesh wrote: > Hi, > > I have packaged CI and openSSI for debian . The source (tar.gz ) and > binary packages for same can be downloaded from > > http://openssi.org/contrib/debian/ > I have found some issues (mostly packaging error ) with the base packages i uploaded yesterday. ( e2fsprogs/devfsd/ are having problems.) I am working on this. I have deleted the uploaded packages as of now. Will inform once i have it fixed. -aneesh |
|
From: Aneesh K. K.V <ane...@di...> - 2003-08-28 04:21:17
|
On Thu, 2003-08-28 at 03:10, Watson, Brian J. (HP) wrote: > Aneesh Kumar K.V wrote: > > Hi, > > > > I have packaged CI and openSSI for debian . The source (tar.gz ) and > > binary packages for same can be downloaded from > > > > http://openssi.org/contrib/debian/ > > It might help if you organized these packages like so: > > debian/ > +---src/ > | +---ci/*.tar.gz > | +---openssi/*.tar.gz > +---binary/ > +---ci/*.deb > +---openssi/*.deb > > Certain packages, such as cluster-tools, would appear in multiple > directories (it could be hard linked). > > You can also eliminate binary packages that we don't modify, such as > util-linux*.deb (only mount*.deb from the util-linux source is > modified). > > Have you given any thought to packaging these .debs as a release? It > seems like a good goal to make the Red Hat and Debian binary releases > look as similar as possible (principle of least surprise for the user). > For example, the Red Hat release has a ./install script for > automatically installing and updating RPMs, as well as running > openssi_configure_cluster to do the initial configuration. We could > separate out the distro specific stuff and use it for both releases. > I will organize the packages as you suggested. My aim of putting those .deb and tar.gz in the contrib section was to get the feedback from other who are willing to give it a try. Once we fix any remaining issues with packaging, we can put it in the same way redhat releases happens now. -aneesh |
|
From: Brian J. W. <Bri...@hp...> - 2003-08-27 21:40:59
|
Aneesh Kumar K.V wrote: > Hi, > > I have packaged CI and openSSI for debian . The source (tar.gz ) and > binary packages for same can be downloaded from > > http://openssi.org/contrib/debian/ It might help if you organized these packages like so: debian/ +---src/ | +---ci/*.tar.gz | +---openssi/*.tar.gz +---binary/ +---ci/*.deb +---openssi/*.deb Certain packages, such as cluster-tools, would appear in multiple directories (it could be hard linked). You can also eliminate binary packages that we don't modify, such as util-linux*.deb (only mount*.deb from the util-linux source is modified). Have you given any thought to packaging these .debs as a release? It seems like a good goal to make the Red Hat and Debian binary releases look as similar as possible (principle of least surprise for the user). For example, the Red Hat release has a ./install script for automatically installing and updating RPMs, as well as running openssi_configure_cluster to do the initial configuration. We could separate out the distro specific stuff and use it for both releases. Brian |
|
From: Aneesh K. K.V <ane...@di...> - 2003-08-27 14:34:31
|
Hi, I have packaged CI and openSSI for debian . The source (tar.gz ) and binary packages for same can be downloaded from http://openssi.org/contrib/debian/ -aneesh |
|
From: Aneesh K. K.V <ane...@di...> - 2003-08-20 06:57:07
|
Hi , I have committed AUTHORS file following the format found with the linux kernel.Request others to add other components . -aneesh |
|
From: Brian J. W. <Bri...@hp...> - 2003-08-10 01:24:56
|
jo...@ne... wrote: > If I read the docs ok, CI is infrastructure that is useful for more > cluster solutions, not only openssi... correct? Does it make sense > to run CI ALONE, so without another cluster tool 'above' it? CI is a basic set of cluster building blocks that don't interfere much with normal kernel operations. Its core feature is a set of APIs for examining the membership of a cluster and registering to receive a signal when a node joins or leaves the cluster. CI includes an automatic heartbeat mechanism to automatically kick a node out if it becomes unresponsive. It also includes a standardized mechanism for kernels on different nodes to talk to one another. OpenSSI builds on CI, but goes much further. It _does_ interfere with normal kernel operation (in a good way) to create the illusion that your cluster is a single, giant SMP. Every node shares the same set of filesystems (including the root), which makes an OpenSSI cluster much easier to manage than other clusters. You only have one place where you need to install, upgrade, and configure software. A process on any node can communicate with processes on any other nodes using ordinary IPC mechanisms (signals, pipes, semaphores, etc.), which makes it much easier to develop distributed applications. Processes and TCP connections can be automatically load balanced across an OpenSSI cluster to ensure optimal usage of your CPUs. An OpenSSI cluster can be configured such that any node can fail and the cluster continues running. OpenSSI provides a general-purpose clustering operating system that can make things easier for almost everyone who needs a cluster to solve a particular problem. On the other hand, CI provides some well-tested building blocks for those few who would prefer to develop their own clustering solution. Hope this helps you understand the relationship between the two, Brian |
|
From: Brian J. W. <Bri...@hp...> - 2003-07-11 07:57:00
|
I just posted the CI 0.9.8 release on ci-linux.sf.net. It now includes both Cluster Tools and the CI kernel patch. The source code has been significantly reorganized. The installation procedure has changed a bit. Another significant change is that SIGCLUSTER has been eliminated. Read the release notes to learn more about this exciting new release. Enjoy! Brian |
|
From: Brian J. W. <Bri...@hp...> - 2003-06-27 05:34:41
|
They're available in the contrib/ directories of the CI and OpenSSI websites, respectively: http://ci-linux.sf.net/contrib/ http://OpenSSI.org/contrib/ The CI kernel patch does not yet include the kernel debugger (kdb). I need to fix the kdb patches in the CVS repository so they apply cleanly. If you want to install OpenSSI, you also need the CI release. Only it includes cluster-tools. These pre-releases are based on vanilla source. Tommorrow I'll roll some based on Red Hat source. This is quite simple now that I've written scripts to automate the generation of source releases. Still on my ToDo before declaring a final 0.9.8 release: - write scripts for automatically generating binary RPM releases - update documentation - do some testing I hope to be done early next week. Note that I'm only going to test the Red Hat based stuff. Those who are interested in the vanilla-based stuff (i.e., Debian users) should test the pre-releases before I finish the real release. Feel free to send me comments. Enjoy! Brian |
|
From: Brian J. W. <Bri...@hp...> - 2003-06-23 21:04:10
|
This was supposed to go out two weeks ago when the new repository was
ready, but I realized today that it never went out. I'm not sure if the
blame lies with me or my mail client. Anyway, here it is.
-Brian
---
CI and OpenSSI developers-
The newly restructured CVS repositories are open for business. I've
updated instructions on the CI and OpenSSI websites:
http://ci-linux.sourceforge.net/index.shtml#cvs
http://openssi.org/index.shtml#cvs
Note that although checking out the OPENSSI-RH branch of either
repository will give you a complete set of docs and code for the kernel
and utilities, not all files actually have an OPENSSI-RH branch. For
files that don't need to be branched, such as cluster-tools,
openssi-tools, some of the docs, etc., I artificially tagged the trunk
of them as OPENSSI-RH. In addition, I tagged the trunk of these files
with COMMON, so I can keep track of who they are.
If you add a new file (or directory of files) that doesn't need to be
branched, you can do this tagging as follows:
$ cvs admin -nCOMMON:1 <filename>
$ cvs admin -nOPENSSI-RH:1 <filename>
If you ever need to branch a file (or directory of files) that was
previously tagged in this manner, you need to remove the COMMON tag and
force the branching:
$ cvs tag -d COMMON <filename>
$ cvs tag -bF OPENSSI-RH <filename>
I also re-created the RH-MERGE and TRUNK-MERGE tags for keeping the
trunk and RH branch in sync. Remember, the RH-MERGE tag is on the trunk
for keeping it in sync with the RH branch, and the TRUNK-MERGE tag is on
the RH branch for keeping it in sync with the trunk. If this sounds to
confusing to most developers, let me know and I'll switch them around.
In the near future, we'll need to modify some of the OpenSSI docs to
reflect the changes. I did this with the CI docs already.
If you need help adapting changes from your old sandboxes to your new
ones, let me know. Aneesh is adapting the build system (basing it on the
GNU autoconf system). If you run into build problems, let him know. As
always, copy the appropriate mailing list so others can benefit from
your experiences.
Enjoy!
-Brian
|
|
From: Brian J. W. <Bri...@hp...> - 2003-06-05 23:04:32
|
Aneesh Kumar K.V wrote:
> I made these changes for cluster-tools to build
>
> --- /home/kvaneesh/SSI-reorg/ci/kernel/include/cluster/ssisys.h Wed Jun
> 4 03:52:31 2003
> +++ ssisys.h Thu Jun 5 18:22:58 2003
> @@ -21,8 +21,11 @@
> *
> */
> #ifndef _CLUSTER_SSISYS_H
> #define _CLUSTER_SSISYS_H
> +/* JAG - Linux version ???? */
> +#define FSTYPSZ 16
> +
This value is now defined in kernel/include/cluster/nsc.h. Grep'ing the
source, I see it's only used in the CFS kernel code. I don't think it
needs to be redefined here.
> @@ -154,8 +157,9 @@
>
> extern long do_ssisys(ssisys_iovec_t *);
> extern long do_discover_mounts(const char *, int);
>
> +#endif /* __KERNEL__ */
> /*
> * IN argument structure used for SSISYS_LDLVL_INIT
> */
> struct ts_ldinit_inargs {
> @@ -371,9 +375,8 @@
> };
> typedef struct ts_get_primary_inargs ts_get_primary_inargs_t;
>
>
> -#endif /* __KERNEL__ */
It looks like there are only two structures in this block that are used
by cluster-tools. The rest of it doesn't need to be exposed outside the
kernel. I've checked in a fix that only exposes what is needed. I've
tested it to make sure it builds.
Brian
|
|
From: Aneesh K. K.V <ane...@di...> - 2003-06-05 04:21:54
|
On Thu, 2003-06-05 at 08:04, Watson, Brian J. (HP) wrote:
> Aneesh Kumar K.V wrote:
> > This required some changes to cluster.h ssisys.h in the kernel
> > directory.
>
> I checked the differences for cluster.h into the new CI repository. I
> didn't see any relevant differences for ssisys.h.
>
I made these changes for cluster-tools to build
--- /home/kvaneesh/SSI-reorg/ci/kernel/include/cluster/ssisys.h Wed Jun
4 03:52:31 2003
+++ ssisys.h Thu Jun 5 18:22:58 2003
@@ -21,8 +21,11 @@
*
*/
#ifndef _CLUSTER_SSISYS_H
#define _CLUSTER_SSISYS_H
+/* JAG - Linux version ???? */
+#define FSTYPSZ 16
+
#include <linux/types.h>
#ifdef __KERNEL__
@@ -154,8 +157,9 @@
extern long do_ssisys(ssisys_iovec_t *);
extern long do_discover_mounts(const char *, int);
+#endif /* __KERNEL__ */
/*
* IN argument structure used for SSISYS_LDLVL_INIT
*/
struct ts_ldinit_inargs {
@@ -371,9 +375,8 @@
};
typedef struct ts_get_primary_inargs ts_get_primary_inargs_t;
-#endif /* __KERNEL__ */
#ifndef __KERNEL__
/*
|
|
From: Brian J. W. <Bri...@hp...> - 2003-06-05 02:40:34
|
Aneesh Kumar K.V wrote: > This required some changes to cluster.h ssisys.h in the kernel > directory. I checked the differences for cluster.h into the new CI repository. I didn't see any relevant differences for ssisys.h. > Also we need to make sure we don't keep the same files in both the > repository. I've fixed this. I've made an attempt to make sure OpenSSI code is turned off if the files are just built for CI. > yes user can override the kernel source directory when configuring by > > ./configure --with-linux_srcdir=<linux-src-dir> Excellent. > We need to keep configure.ac in ci directory since running > > automake --add-missing in the ci/cluster-tools will throw this error. > > kvaneesh@gfsserv:~/SSI-reorg/ci-test/cluster-tools$ automake > --add-missing > Makefile.am: required file `./NEWS' not found > Makefile.am: required file `./README' not found > Makefile.am: required file `./AUTHORS' not found > Makefile.am: required file `./ChangeLog' not found Isn't there a way to override this behavior if we had to? Nevertheless, I like your argument that 'make install' should install all of the OpenSSI utilities. I'm just concerned about problems passing configuration options to all the various third-party utilities. > We need to delete ci/cluster-tools/configure.ac. I've put in a request for SF to do this. > As you can also see from the changes i did, no > Makefiles are generated in ci/ directory. configure creates related > Makefiles under ci/cluster-tools/ directory only . So the procedure to > build is > > cd ci > < All the steps need to configure > > cd cluster-tools > make > make install Maybe we can put a simple Makefile.am in the root that passes along 'make' and 'make install' to cluster-tools. This behavior would be even more useful in the OpenSSI repository. Brian |
|
From: Aneesh K. K.V <ane...@di...> - 2003-06-04 07:06:50
|
On Wed, 2003-06-04 at 10:16, Watson, Brian J. (HP) wrote: > Aneesh- > > The new CI repository is ready for you to fix up the cluster-tools build > > system. It should be relatively easy, since most of the changes involved > > removing files. Only the cmd, libcluster, and man directories remain, > and some of the stuff from cmd and man have been removed. As I described > > in a previous e-mail, they're moving to the OpenSSI repository. > > One significant change is that I removed the include directory. This > stuff should be fetched from the kernel source so that we don't have two This required some changes to cluster.h ssisys.h in the kernel directory. I am not committing changes for the same. But once we have openssi repository also reorganised I guess we can fix these issues. Also we need to make sure we don't keep the same files in both the repository. > > copies to keep in sync. The kernel directory of the CI repository > contains these header files, although for better generality the > configure script could allow the user to override this kernel source > location. yes user can override the kernel source directory when configuring by ./configure --with-linux_srcdir=<linux-src-dir> > > Note that my original e-mail about the reorg envisioned configure.ac > being in the root of the CI repository. I now think I prefer to have it > in cluster-tools, like it was. The only thing it's used for building is > cluster-tools, anyway. I'm not sure we want to automatically build the > kernel with it. > We need to keep configure.ac in ci directory since running automake --add-missing in the ci/cluster-tools will throw this error. kvaneesh@gfsserv:~/SSI-reorg/ci-test/cluster-tools$ automake --add-missing Makefile.am: required file `./NEWS' not found Makefile.am: required file `./README' not found Makefile.am: required file `./AUTHORS' not found Makefile.am: required file `./ChangeLog' not found I have modified ci/configure.ac. We need to delete ci/cluster-tools/configure.ac. Once you confirm on the above changes we can delete the same.As you can also see from the changes i did, no Makefiles are generated in ci/ directory. configure creates related Makefiles under ci/cluster-tools/ directory only . So the procedure to build is cd ci < All the steps need to configure > cd cluster-tools make make install > I'm also concerned about the precedent it would set for the OpenSSI > repository. Originally I thought it could have a configure.ac that > configured and built all of the OpenSSI utilities (openssi-tools, > util-linux, ipvsadm, etc.), but I'm afraid it would get too complicated > to deal with the various configuration options each of them have. > Besides, I think in the long-term that most developers and users will > install binary packages and just build from source the stuff they want > to customize or enhance. > I will look into this once openssi repository reorganisation is finished. Ideally i would expect one make install to install the entire set of utilities for me. -aneesh |
|
From: Brian J. W. <Bri...@hp...> - 2003-06-04 04:49:03
|
Aneesh- The new CI repository is ready for you to fix up the cluster-tools build system. It should be relatively easy, since most of the changes involved removing files. Only the cmd, libcluster, and man directories remain, and some of the stuff from cmd and man have been removed. As I described in a previous e-mail, they're moving to the OpenSSI repository. One significant change is that I removed the include directory. This stuff should be fetched from the kernel source so that we don't have two copies to keep in sync. The kernel directory of the CI repository contains these header files, although for better generality the configure script could allow the user to override this kernel source location. Note that my original e-mail about the reorg envisioned configure.ac being in the root of the CI repository. I now think I prefer to have it in cluster-tools, like it was. The only thing it's used for building is cluster-tools, anyway. I'm not sure we want to automatically build the kernel with it. I'm also concerned about the precedent it would set for the OpenSSI repository. Originally I thought it could have a configure.ac that configured and built all of the OpenSSI utilities (openssi-tools, util-linux, ipvsadm, etc.), but I'm afraid it would get too complicated to deal with the various configuration options each of them have. Besides, I think in the long-term that most developers and users will install binary packages and just build from source the stuff they want to customize or enhance. The new CI repository can be checked out with this command: cvs -d:ext:kva...@cv...:/cvsroot/ci-linux co ci The OpenSSI repository will be ready tommorrow or the following day. Thanks for helping me out with this, Brian |
|
From: Brian J. W. <Bri...@hp...> - 2003-06-03 23:55:57
|
Brian J. Watson wrote: > I agree with your suggestions. I would also like to insert the following > line into the ChangeLog every time I roll a release: > > DD/MM/YYYY CI x.x.x > -- or -- > DD/MM/YYYY OpenSSI x.x.x One other suggestion is that we stop including CI changes in the OpenSSI ChangeLog. When I roll OpenSSI releases, I'll just copy in the CI ChangeLog as ChangeLog.ci. We don't need to have the two integrated together. Brian |
|
From: Aneesh K. K.V <ane...@di...> - 2003-06-03 07:06:44
|
On Tue, 2003-06-03 at 12:20, Brian J. Watson wrote: [..snip..] > > I was thinking that myself. What do you think, Aneesh? > Fine. We just need to capture the date of change. -aneesh |
|
From: Brian J. W. <Bri...@hp...> - 2003-06-03 06:52:28
|
Dave Close wrote: > "Brian J. Watson" wrote: > >>I agree with your suggestions. I would also like to insert the following >>line into the ChangeLog every time I roll a release: >>DD/MM/YYYY CI x.x.x >> -- or -- >>DD/MM/YYYY OpenSSI x.x.x > > > May I suggest a less internationally ambiguous format: YYYY/MM/DD. > Also complies with ANSI and ISO standards. I was thinking that myself. What do you think, Aneesh? Brian |
|
From: Aneesh K. K.V <ane...@di...> - 2003-06-03 03:32:27
|
On Tue, 2003-06-03 at 05:52, Brian J. Watson wrote: > Aneesh Kumar K.V wrote: > > I agree with your suggestions. I would also like to insert the following > line into the ChangeLog every time I roll a release: > > DD/MM/YYYY CI x.x.x > -- or -- > DD/MM/YYYY OpenSSI x.x.x > > Sound okay? > Great !!! -aneesh |
|
From: Aneesh K. K.V <ane...@di...> - 2003-06-03 03:31:03
|
On Tue, 2003-06-03 at 06:00, Brian J. Watson wrote: > Aneesh- > > Can you help me adapt the configure.ac and Makefile.am files? I'll > checkin a first cut at them today, but you're more experienced than I at > getting them right. :) > I will take care of Makefile.am and configure.ac changes. -aneesh |
|
From: Brian J. W. <Bri...@hp...> - 2003-06-03 00:33:08
|
Aneesh Kumar K.V wrote: > It would be better if we wait for a day or so and say no more submits > and then reorganise.Then we can get the reorganised RH branch and Trunk > built and then open up the CVS for further submit. To all developers- It's time to implement this reorg. Please don't check anything into the repositories. After I finish updating them, I can help you adapt your sandboxes to the new code organization. Aneesh- Can you help me adapt the configure.ac and Makefile.am files? I'll checkin a first cut at them today, but you're more experienced than I at getting them right. :) -Brian |
|
From: Brian J. W. <Bri...@hp...> - 2003-06-03 00:24:49
|
Aneesh Kumar K.V wrote: > Then i would request to start with fresh ChangeLogs with new formats for > both the repository and old Changelogs can be renamed. > > ie in the SSI repository we will have > ChangeLog and ChangeLog.0( This is the old Changelog ). ChangeLog will > have the first line as previous cluster-tools ChangeLog can be found at > so and so place > > > in the ci we will have ChangeLog,ChangeLog.0( this is ci-linux change > log ) and ChangeLog.cluster-tools( this is cluster-tools changelog ) and > we will have a new entry in ChangeLog saying the old cluster-tools > ChangeLog can be found in ChangeLog.cluster-tools. > > I would also say that the ChangeLog fromat can be > > DD/MM/YYYY username <useremailaddress> > * Changes > > see this . > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/opendlm/opendlm/ChangeLog?rev=HEAD&content-type=text/plain > > I found this format pretty useful when tracking bugs. I agree with your suggestions. I would also like to insert the following line into the ChangeLog every time I roll a release: DD/MM/YYYY CI x.x.x -- or -- DD/MM/YYYY OpenSSI x.x.x Sound okay? Brian |
|
From: Aneesh K. K.V <ane...@di...> - 2003-05-23 05:33:35
|
On Fri, 2003-05-23 at 10:48, Brian J. Watson wrote: > Aneesh Kumar K.V wrote: > > It would be better if we wait for a day or so and say no more submits > > and then reorganise.Then we can get the reorganised RH branch and Trunk > > built and then open up the CVS for further submit. > > That's my plan. I'm giving a few days for comments, then I'm going to > ask everyone to refrain from checkins while I do the reorg. Then I'll > help developers adapt their sandboxes to the new structure. > > > > How are you going to organise the Changelog .I mean what about the > > previous contents. ? > > I'm thinking of ditching the old changes and starting afresh. The > history of cluster-tools and ci-linux as separate releases is not that > interesting going forward. > > Then i would request to start with fresh ChangeLogs with new formats for both the repository and old Changelogs can be renamed. ie in the SSI repository we will have ChangeLog and ChangeLog.0( This is the old Changelog ). ChangeLog will have the first line as previous cluster-tools ChangeLog can be found at so and so place in the ci we will have ChangeLog,ChangeLog.0( this is ci-linux change log ) and ChangeLog.cluster-tools( this is cluster-tools changelog ) and we will have a new entry in ChangeLog saying the old cluster-tools ChangeLog can be found in ChangeLog.cluster-tools. I would also say that the ChangeLog fromat can be DD/MM/YYYY username <useremailaddress> * Changes see this . http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/opendlm/opendlm/ChangeLog?rev=HEAD&content-type=text/plain I found this format pretty useful when tracking bugs. > > install-deb-initscripts is not needed this job is now done by > > openssi_cluster_create. -aneesh |
|
From: Brian J. W. <Bri...@hp...> - 2003-05-23 05:19:05
|
Aneesh Kumar K.V wrote: > It would be better if we wait for a day or so and say no more submits > and then reorganise.Then we can get the reorganised RH branch and Trunk > built and then open up the CVS for further submit. That's my plan. I'm giving a few days for comments, then I'm going to ask everyone to refrain from checkins while I do the reorg. Then I'll help developers adapt their sandboxes to the new structure. > How are you going to organise the Changelog .I mean what about the > previous contents. ? I'm thinking of ditching the old changes and starting afresh. The history of cluster-tools and ci-linux as separate releases is not that interesting going forward. > install-deb-initscripts is not needed this job is now done by > openssi_cluster_create. Okay. I'll eliminate it. >>| | | `-- rcSSI >>| | `-- specs >>| | `-- init-scripts.spec > > > I guess init-script.spec is going to be script which will help in > building debian packages. In RPM-land, a .spec file provides instructions on how to build the binaries for a package, specifies dependencies on other packages, includes a description of what the package does, etc. Debian might use something different to build its own packages. I'm not sure what. > Can't we drop addnode and addnode.dev and use openssi_cluster_create > and openssi_addnode Not yet. I want to play with them first, make some comments, and see what needs to be changed in the documentation. We can cross this bridge after finishing the reorg. BTW, Scott's change to add PXE support will help me do this. It's been awhile since I've used a test cluster that can do Etherboot, so I haven't even played with the original addnode for a long time. :( >>Let me know what you think, > > Great!!!!. Thanks!! Brian |
|
From: Aneesh K. K.V <ane...@di...> - 2003-05-22 05:06:35
|
On Thu, 2003-05-22 at 10:07, Aneesh Kumar K.V wrote: > You may want to wait for the changes done yesterday by laura to be > merged back to the trunk before reorganising the CVS. Also cluster-tools > patch from Scott also need to be not applied. That should be read as patch from Scott NEED to be Applied. -aneesh |
1 message has been excluded from this view by a project administrator.
