From: Joel Becker <Joel.Becker@oracle.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees
Date: Fri, 14 Nov 2008 09:37:43 -0800 [thread overview]
Message-ID: <20081114173743.GC18678@ca-server1.us.oracle.com> (raw)
In-Reply-To: <20081114172530.GB4054@redhat.com>
On Fri, Nov 14, 2008 at 11:25:30AM -0600, David Teigland wrote:
> On Fri, Nov 14, 2008 at 10:18:13AM +0100, Fabio M. Di Nitto wrote:
> > At this point we haven't really settled how many (sub) project will be
> > created out of this split. This will come once we agree how to split.
>
> I like the third option as long as the number of new git trees doesn't
> explode (obviously no one wants 10 new git trees.) Not to get ahead of
> you, but for my own curiosity I looked at what minimum number of git trees
> I'd have to start juggling... it's not too bad, but more than this might
> get out of hand.
Obviously I like the third option, as I proposed it :-) But I
think Dave's really nailed how to split it out. Originally, I expected
that his fence.git, fence-agents.git, cman.git, and rgmanager.git would
stay together as one tree, and that gfs and its utilities would also be
one tree. Looking at it, though, I think he's right we split them out.
That's a result from our plan at the summit to start converging fence
agents and then eventually move fencing up the stack. And I can tell
you from experience that separate kernel and tools trees for a
filesystem (ocfs2.git, ocfs2-tools.git) is a much nicer way to go.
Joel
> dlm.git:
> libdlm, dlm_controld, libdlmcontrol, dlm_tool
>
> fence.git:
> libfence, fenced, libfenced, fence_tool, fence_node
>
> fence-agents.git:
> <lots>
>
> cman.git:
> libcman, cman_tool, cmannotifyd, qdiskd, mkqdisk
> cluster/config/*
> move plugins into corosync tree?
> group_tool (groupd/libgroup won't exist, group_tool will just be a
> wrapper/shortcut for fence_tool/dlm_tool/gfs_control queries;
> maybe include queries of other related daemons, like ocfs2_controld?)
>
> gfs2-utils.git:
> gfs_controld, libgfscontrol, gfs_control
> mount.gfs2, mount.gfs, libgfs, libgfs2
> gfs_debug, gfs_fsck, gfs_grow, gfs_jadd, gfs_mkfs, gfs_quota, gfs_tool
> gfs2_convert, gfs2_edit, gfs2_fsck, gfs2_mkfs, gfs2_quota, gfs2_tool
>
> gfs-kernel.git:
> gfs.ko
>
> rgmanager.git:
>
> gnbd goes away
> cmirror moves away
>
--
"There are only two ways to live your life. One is as though nothing
is a miracle. The other is as though everything is a miracle."
- Albert Einstein
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127
WARNING: multiple messages have this Message-ID (diff)
From: Joel Becker <Joel.Becker@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees
Date: Fri, 14 Nov 2008 09:37:43 -0800 [thread overview]
Message-ID: <20081114173743.GC18678@ca-server1.us.oracle.com> (raw)
In-Reply-To: <20081114172530.GB4054@redhat.com>
On Fri, Nov 14, 2008 at 11:25:30AM -0600, David Teigland wrote:
> On Fri, Nov 14, 2008 at 10:18:13AM +0100, Fabio M. Di Nitto wrote:
> > At this point we haven't really settled how many (sub) project will be
> > created out of this split. This will come once we agree how to split.
>
> I like the third option as long as the number of new git trees doesn't
> explode (obviously no one wants 10 new git trees.) Not to get ahead of
> you, but for my own curiosity I looked at what minimum number of git trees
> I'd have to start juggling... it's not too bad, but more than this might
> get out of hand.
Obviously I like the third option, as I proposed it :-) But I
think Dave's really nailed how to split it out. Originally, I expected
that his fence.git, fence-agents.git, cman.git, and rgmanager.git would
stay together as one tree, and that gfs and its utilities would also be
one tree. Looking at it, though, I think he's right we split them out.
That's a result from our plan at the summit to start converging fence
agents and then eventually move fencing up the stack. And I can tell
you from experience that separate kernel and tools trees for a
filesystem (ocfs2.git, ocfs2-tools.git) is a much nicer way to go.
Joel
> dlm.git:
> libdlm, dlm_controld, libdlmcontrol, dlm_tool
>
> fence.git:
> libfence, fenced, libfenced, fence_tool, fence_node
>
> fence-agents.git:
> <lots>
>
> cman.git:
> libcman, cman_tool, cmannotifyd, qdiskd, mkqdisk
> cluster/config/*
> move plugins into corosync tree?
> group_tool (groupd/libgroup won't exist, group_tool will just be a
> wrapper/shortcut for fence_tool/dlm_tool/gfs_control queries;
> maybe include queries of other related daemons, like ocfs2_controld?)
>
> gfs2-utils.git:
> gfs_controld, libgfscontrol, gfs_control
> mount.gfs2, mount.gfs, libgfs, libgfs2
> gfs_debug, gfs_fsck, gfs_grow, gfs_jadd, gfs_mkfs, gfs_quota, gfs_tool
> gfs2_convert, gfs2_edit, gfs2_fsck, gfs2_mkfs, gfs2_quota, gfs2_tool
>
> gfs-kernel.git:
> gfs.ko
>
> rgmanager.git:
>
> gnbd goes away
> cmirror moves away
>
--
"There are only two ways to live your life. One is as though nothing
is a miracle. The other is as though everything is a miracle."
- Albert Einstein
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127
next prev parent reply other threads:[~2008-11-14 17:37 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-14 9:18 [Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees Fabio M. Di Nitto
2008-11-14 9:18 ` [Ocfs2-devel] " Fabio M. Di Nitto
2008-11-14 9:29 ` [Cluster-devel] " Steven Whitehouse
2008-11-14 9:29 ` [Ocfs2-devel] " Steven Whitehouse
2008-11-14 9:33 ` Christine Caulfield
2008-11-14 9:34 ` [Ocfs2-devel] " Christine Caulfield
2008-11-17 23:36 ` [Pacemaker] " Mark Fasheh
2008-11-17 23:36 ` [Ocfs2-devel] " Mark Fasheh
2008-11-14 9:50 ` [Ocfs2-devel] [Pacemaker] " Andrew Beekhof
2008-11-14 10:06 ` [Cluster-devel] " Fabio M. Di Nitto
2008-11-14 10:06 ` [Ocfs2-devel] " Fabio M. Di Nitto
2008-11-14 11:34 ` Andrew Beekhof
[not found] ` <26ef5e70811140333v480b8c05v1e448b525c48279f@mail.gmail.com>
[not found] ` <Pine.LNX.4.64.0811141304030.7841@trider-g7>
[not found] ` <26ef5e70811140418s32d38a22ta7b9693c2df13f08@mail.gmail.com>
2008-11-14 12:40 ` [Cluster-devel] " Fabio M. Di Nitto
2008-11-14 17:25 ` [Cluster-devel] " David Teigland
2008-11-14 17:25 ` [Ocfs2-devel] " David Teigland
2008-11-14 17:37 ` Joel Becker [this message]
2008-11-14 17:37 ` Joel Becker
2008-11-14 21:11 ` Andrew Beekhof
2008-11-14 21:57 ` David Teigland
2008-11-14 21:57 ` David Teigland
2008-11-14 22:33 ` Subhendu Ghosh
2008-11-14 22:33 ` Subhendu Ghosh
2008-11-15 7:11 ` Andrew Beekhof
2008-11-17 5:52 ` Fabio M. Di Nitto
2008-11-17 5:52 ` Fabio M. Di Nitto
2008-11-17 8:52 ` Andrew Beekhof
2008-11-17 10:02 ` Fabio M. Di Nitto
2008-11-17 10:02 ` Fabio M. Di Nitto
2008-11-17 10:25 ` Andrew Beekhof
2008-11-17 10:37 ` Fabio M. Di Nitto
2008-11-17 10:37 ` Fabio M. Di Nitto
2008-11-17 12:06 ` Andrew Beekhof
2008-11-17 5:46 ` Fabio M. Di Nitto
2008-11-17 5:46 ` Fabio M. Di Nitto
2008-11-17 5:45 ` Fabio M. Di Nitto
2008-11-17 5:45 ` [Ocfs2-devel] " Fabio M. Di Nitto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081114173743.GC18678@ca-server1.us.oracle.com \
--to=joel.becker@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.