[Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Fabio M. Di Nitto]

Hi everybody,

as discussed and agreed at the Cluster Summit we need to split our tree
to make life easier in the long run (etc. etc.).

We need to decide how we want to do it and there are different
approaches to that. I was able to think of 3. There might be more and I
might not have taken everything into consideration so comments and ideas
are welcome.

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.

= first approach =

We maintain cluster.git as single entity with all source code in one
place. We change the build system in such a way each single component
can be released standalone (similar to how it was done in the RHEL*
branches).

Pro:
 - preserve current development model.
 - allow release of separate tarball for each (sub) project.
 - external users don't need to build the whole tree for one (sub)
project.

Cons:
 - move all the burden to the build system (by duplicating tons of
stuff, maybe solvable but needs investigation) and release manager.
 - tagging for releases will require changes as it's not possible to tag
only one (sub) project.

= second approach =

We maintain cluster.git as single entity. Each (sub) project would
become a separate branch.

So for example all the gnbd code will be branched into master-gnbd (and
so on for all the others).

Checking out one specific HEAD will only show the code for that project.

Pro:
 - cleaner look at the tree.
 - partially preserve current development model (still easy to cherry
pick changes between branches)
 - external users don't need to build the whole tree.

Cons:
 - more expensive branch management.
 - tagging for releases will require small changes.

= third approach =

We copy cluster.git N times for each (sub) project, clean the master
branch to match only that (sub)project.

Pro:
 - very clean tree from checkout
 - each (sub) project is really separated and will have its own
identity.
 - external users don't need to build the whole tree.
 - easier to fine tune access to each single component (for example we
can allow user foo to access dlm but not gfs... or whatever combination)

Cons:
 - more complex process to perform cherry-pick between branches.
 - higher risk to commit fixes in one branch and forget in another.
 - requires a lot more developer attention.

Fabio

[Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Steven Whitehouse]

Hi,

I'm not so keen on option #2, but aside from that I have no strong
opinions,

Steve.

On Fri, 2008-11-14 at 10:18 +0100, Fabio M. Di Nitto wrote:
> Hi everybody,
> 
> as discussed and agreed at the Cluster Summit we need to split our tree
> to make life easier in the long run (etc. etc.).
> 
> We need to decide how we want to do it and there are different
> approaches to that. I was able to think of 3. There might be more and I
> might not have taken everything into consideration so comments and ideas
> are welcome.
> 
> 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.
> 
> = first approach =
> 
> We maintain cluster.git as single entity with all source code in one
> place. We change the build system in such a way each single component
> can be released standalone (similar to how it was done in the RHEL*
> branches).
> 
> Pro:
>  - preserve current development model.
>  - allow release of separate tarball for each (sub) project.
>  - external users don't need to build the whole tree for one (sub)
> project.
> 
> Cons:
>  - move all the burden to the build system (by duplicating tons of
> stuff, maybe solvable but needs investigation) and release manager.
>  - tagging for releases will require changes as it's not possible to tag
> only one (sub) project.
> 
> = second approach =
> 
> We maintain cluster.git as single entity. Each (sub) project would
> become a separate branch.
> 
> So for example all the gnbd code will be branched into master-gnbd (and
> so on for all the others).
> 
> Checking out one specific HEAD will only show the code for that project.
> 
> Pro:
>  - cleaner look at the tree.
>  - partially preserve current development model (still easy to cherry
> pick changes between branches)
>  - external users don't need to build the whole tree.
> 
> Cons:
>  - more expensive branch management.
>  - tagging for releases will require small changes.
> 
> = third approach =
> 
> We copy cluster.git N times for each (sub) project, clean the master
> branch to match only that (sub)project.
> 
> Pro:
>  - very clean tree from checkout
>  - each (sub) project is really separated and will have its own
> identity.
>  - external users don't need to build the whole tree.
>  - easier to fine tune access to each single component (for example we
> can allow user foo to access dlm but not gfs... or whatever combination)
> 
> Cons:
>  - more complex process to perform cherry-pick between branches.
>  - higher risk to commit fixes in one branch and forget in another.
>  - requires a lot more developer attention.
> 
> Fabio
> 

[Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Christine Caulfield]

Fabio M. Di Nitto wrote:
> Hi everybody,
> 
> as discussed and agreed at the Cluster Summit we need to split our tree
> to make life easier in the long run (etc. etc.).
> 
> We need to decide how we want to do it and there are different
> approaches to that. I was able to think of 3. There might be more and I
> might not have taken everything into consideration so comments and ideas
> are welcome.
> 
> 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.
> 
> = first approach =
> 
> We maintain cluster.git as single entity with all source code in one
> place. We change the build system in such a way each single component
> can be released standalone (similar to how it was done in the RHEL*
> branches).
> 
> Pro:
>  - preserve current development model.
>  - allow release of separate tarball for each (sub) project.
>  - external users don't need to build the whole tree for one (sub)
> project.
> 
> Cons:
>  - move all the burden to the build system (by duplicating tons of
> stuff, maybe solvable but needs investigation) and release manager.
>  - tagging for releases will require changes as it's not possible to tag
> only one (sub) project.
> 
> = second approach =
> 
> We maintain cluster.git as single entity. Each (sub) project would
> become a separate branch.
> 
> So for example all the gnbd code will be branched into master-gnbd (and
> so on for all the others).
> 
> Checking out one specific HEAD will only show the code for that project.
> 
> Pro:
>  - cleaner look at the tree.
>  - partially preserve current development model (still easy to cherry
> pick changes between branches)
>  - external users don't need to build the whole tree.
> 
> Cons:
>  - more expensive branch management.
>  - tagging for releases will require small changes.
> 
> = third approach =
> 
> We copy cluster.git N times for each (sub) project, clean the master
> branch to match only that (sub)project.
> 
> Pro:
>  - very clean tree from checkout
>  - each (sub) project is really separated and will have its own
> identity.
>  - external users don't need to build the whole tree.
>  - easier to fine tune access to each single component (for example we
> can allow user foo to access dlm but not gfs... or whatever combination)
> 
> Cons:
>  - more complex process to perform cherry-pick between branches.
>  - higher risk to commit fixes in one branch and forget in another.
>  - requires a lot more developer attention.


I think I would votes for 3, 1, 2 in that order.

3 is definitely the best option IMHO. The cons don't make much
difference really - as I understand it, we're not splitting branches but
projects so there will be no, or very little, need to copy fixes across
git trees. Even for the few occasions when it might be necessary, git is
quite capable of generating usable patches.

2 is an inholy mess and an abuse of git's branching system I think.
Please don't do this!

1 is more trouble than it sounds - speaking from experience with the old
RHEL4 tree. You have a tree that looks like it's self-contained, but you
still have to install bits of it to make things build properly. That's
just confusing and annoying.

Chrissie

[Cluster-devel] Re: [Pacemaker] [RFC] Splitting cluster.git into separate projects/trees

[Fabio M. Di Nitto]

On Fri, 14 Nov 2008, Andrew Beekhof wrote:

> Top-posting...
>
> #1 is what the current "situation" evolved from so I think its pretty
> clear that despite the best of intentions, it doesn't work out (far
> too easy for cross-dependancies to develop).
>
> #2 - I share chrissie's feelings on this one ;-)
>
> #3 - Thats got my vote - basically what we did with Pacemaker.
>
> The biggest question here is do you want old versions of the split out
> code to be buildable?

I am not 100% sure I understand what you mean..

> Obviously you'd keep the combined repo somewhere, but you may also
> want to be able to build old versions from within the split-out repo.
> If people don't want this, the split out repos _could_ be filtered
> copies (smaller and only contains relevant history).

the only tree that will be authoritative for all versions before the split 
will still be cluster.git. I'd like for all the other trees to preserve 
history for that specific bit. Maybe git allows to purge all unrelated 
commits from the history, but I personally don't know.

Please remember that cluster.git will not die completely. Some RH specific 
bits might still live there in future.

So basically what will happen for #3 is (more or less):

cp -rp cluster.git dlm.git

clone/checkout dlm.git
purge everything unrelated and cleanup all unrelated history/commits
fix build system/Makefile
tag and make first release
remove dlm from cluster.git

(optionally to keep the tree in a decent state while we split)
make it buildable with external entity
tag/release

Fabio


>
>
> On Fri, Nov 14, 2008 at 10:18, Fabio M. Di Nitto <fdinitto@redhat.com> wrote:
>> Hi everybody,
>>
>> as discussed and agreed at the Cluster Summit we need to split our tree
>> to make life easier in the long run (etc. etc.).
>>
>> We need to decide how we want to do it and there are different
>> approaches to that. I was able to think of 3. There might be more and I
>> might not have taken everything into consideration so comments and ideas
>> are welcome.
>>
>> 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.
>>
>> = first approach =
>>
>> We maintain cluster.git as single entity with all source code in one
>> place. We change the build system in such a way each single component
>> can be released standalone (similar to how it was done in the RHEL*
>> branches).
>>
>> Pro:
>>  - preserve current development model.
>>  - allow release of separate tarball for each (sub) project.
>>  - external users don't need to build the whole tree for one (sub)
>> project.
>>
>> Cons:
>>  - move all the burden to the build system (by duplicating tons of
>> stuff, maybe solvable but needs investigation) and release manager.
>>  - tagging for releases will require changes as it's not possible to tag
>> only one (sub) project.
>>
>> = second approach =
>>
>> We maintain cluster.git as single entity. Each (sub) project would
>> become a separate branch.
>>
>> So for example all the gnbd code will be branched into master-gnbd (and
>> so on for all the others).
>>
>> Checking out one specific HEAD will only show the code for that project.
>>
>> Pro:
>>  - cleaner look at the tree.
>>  - partially preserve current development model (still easy to cherry
>> pick changes between branches)
>>  - external users don't need to build the whole tree.
>>
>> Cons:
>>  - more expensive branch management.
>>  - tagging for releases will require small changes.
>>
>> = third approach =
>>
>> We copy cluster.git N times for each (sub) project, clean the master
>> branch to match only that (sub)project.
>>
>> Pro:
>>  - very clean tree from checkout
>>  - each (sub) project is really separated and will have its own
>> identity.
>>  - external users don't need to build the whole tree.
>>  - easier to fine tune access to each single component (for example we
>> can allow user foo to access dlm but not gfs... or whatever combination)
>>
>> Cons:
>>  - more complex process to perform cherry-pick between branches.
>>  - higher risk to commit fixes in one branch and forget in another.
>>  - requires a lot more developer attention.
>>
>> Fabio
>>
>>
>> _______________________________________________
>> Pacemaker mailing list
>> Pacemaker at clusterlabs.org
>> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>>
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>


--
I'm going to make him an offer he can't refuse.

[Cluster-devel] Re: [Pacemaker] [RFC] Splitting cluster.git into separate projects/trees

[Fabio M. Di Nitto]

On Fri, 14 Nov 2008, Andrew Beekhof wrote:

> On Fri, Nov 14, 2008 at 13:05, Fabio M. Di Nitto <fdinitto@redhat.com> wrote:
>> On Fri, 14 Nov 2008, Andrew Beekhof wrote:
>>
>>> On Fri, Nov 14, 2008 at 11:06, Fabio M. Di Nitto <fdinitto@redhat.com>
>>> wrote:
>>>>
>>>> On Fri, 14 Nov 2008, Andrew Beekhof wrote:
>>>>
>>>>> Top-posting...
>>>>>
>>>>> #1 is what the current "situation" evolved from so I think its pretty
>>>>> clear that despite the best of intentions, it doesn't work out (far
>>>>> too easy for cross-dependancies to develop).
>>>>>
>>>>> #2 - I share chrissie's feelings on this one ;-)
>>>>>
>>>>> #3 - Thats got my vote - basically what we did with Pacemaker.
>>>>>
>>>>> The biggest question here is do you want old versions of the split out
>>>>> code to be buildable?
>>>>
>>>> I am not 100% sure I understand what you mean..
>>>
>>> Perhaps an example from our split...
>>>
>>> The Pacemaker repo includes the _entire_ Heartbeat history up until the
>>> split.
>>> This allows me to build versions of the crm from before the split
>>> (handy if you're doing "hg bisect" to track down which changeset broke
>>> something).
>>
>> Oh yeah ,, that's the same thing I think I suggested.
>
> Actually its the opposite :-)

does it show that much that I have a flu and fever?

>
>> Maybe I didn't express
>> myself properly but I want the full history for the sub project but not of
>> unrelated stuff.
>>
>> So dlm.git will have the full dlm history up to HEAD/master. but it will not
>> have cman history inside.
>
> Thats basically what I did for the GUI.
> Which is fine, it just means you wont be able to build pre-split
> versions of the dlm from within dlm.git

So it's ok, we don't want to build old version dlm from dlm.git before the 
split. That can be and should be done from cluster.git as single reference 
point.

Fabio

--
I'm going to make him an offer he can't refuse.

[Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[David Teigland]

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.

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

[Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Joel Becker]

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

[Ocfs2-devel] [Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[David Teigland]

On Fri, Nov 14, 2008 at 10:11:00PM +0100, Andrew Beekhof wrote:
> I'd have thought fence.git and fence-agents.git in one and cman.git
> and rgmanager.git in another.
> But I may be missing some of the interdependencies.

I wouldn't mind either of those combinations.  Maybe rgmanager's last
stand will be in cluster.git anyway... if so, then it's not a factor.

I didn't have much reason for separating fence/fence-agents.  We're
planning on unifying it all anyway, even if the agents are done sooner.
And I don't think packaging/releasing agents separately should have much
bearing on the source tree?  (I've heard interest in putting agents in
their own package for Fedora.)

Dave

[Ocfs2-devel] [Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Subhendu Ghosh]

David Teigland wrote:
> On Fri, Nov 14, 2008 at 10:11:00PM +0100, Andrew Beekhof wrote:
>> I'd have thought fence.git and fence-agents.git in one and cman.git
>> and rgmanager.git in another.
>> But I may be missing some of the interdependencies.
> 
> I wouldn't mind either of those combinations.  Maybe rgmanager's last
> stand will be in cluster.git anyway... if so, then it's not a factor.
> 
> I didn't have much reason for separating fence/fence-agents.  We're
> planning on unifying it all anyway, even if the agents are done sooner.
> And I don't think packaging/releasing agents separately should have much
> bearing on the source tree?  (I've heard interest in putting agents in
> their own package for Fedora.)
> 
> Dave
> 
> 

Cobbler is also starting to use the fence agents in a totally non-cluster 
related way.  So some separate of  fence/fenced from fence agents - at least 
on the packaging end - would be really useful

-subhendu

[Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Fabio M. Di Nitto]

On Fri, 2008-11-14 at 11:25 -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.)

Ok it looks like we all agree on splitting into different trees (option
three).

The main reason why I didn't want to suggest the trees is because I
don't have yet a full picture of what needs to be split.
Specially we have some circular build dependencies that will require
work for all of this to fit together properly and it's not clear to me
yet what is going to change or how.

I can't say yet how many trees there will be at the end of the process
but we are around 8/10.
On the other hand, I don't think anybody except me should really worry
about that. Your development focus will rarely span across more than 2/3
trees. You will get the other components as updates for your distro on a
regular base (using the OpenSUSE build service to provide "crack-of-day"
packages).

Maybe cluster.git master will turn into a simple set of Makefiles that
will just pull all the trees for you to build always the very latest
making transparent how many trees you are actually working on...

>   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.

No worries :)

> 
> dlm.git:
>   libdlm, dlm_controld, libdlmcontrol, dlm_tool

+1

> 
> fence.git:
>   libfence, fenced, libfenced, fence_tool, fence_node

+1

> 
> fence-agents.git:
>   <lots>
> 

I want to keep this separated from fence related daemons. Agents are
very often updated for bug fixes and to support new firmware at a much
higher speed than the daemons.

> 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?)


We will need a cluster-infrastructure.git (*) tree that will contain all
the basic components. That would be all the cluster/config, init
scripts, liblogthread.

cman.git will contain libcman, cman_tool, cmannotifyd and possibly
group_tool as long as it can build without any of the includes from the
daemons it needs to query.

I am not entirely sure qdisk should live in cman.git. Maybe it's big
enough to live in its own tree by now.

(*) name to be defined ;)

> 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

While I generally agree that kernel and userland should be separated, I
think gfs1 should live in one project and gfs2 in another one. With gfs1
including both userland and kernel.

gfs1 will be phased out sooner or later. easier to have it contained in
one place.

> rgmanager.git:

I haven't made up my mind on this one yet.

> gnbd goes away

indeed.

> cmirror moves away

this is already out of the tree from master.

[Ocfs2-devel] [Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Fabio M. Di Nitto]

On Fri, 2008-11-14 at 22:11 +0100, Andrew Beekhof wrote:
> On Fri, Nov 14, 2008 at 18:37, Joel Becker <Joel.Becker@oracle.com> wrote:
> > 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.
> 
> I'd have thought fence.git and fence-agents.git in one and cman.git
> and rgmanager.git in another.
> But I may be missing some of the interdependencies.
> 
> > 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.
> 
> I think we can do that and have them stay together - for instance
> we're thinking of putting the resource agents and the lrmd which
> drives them together in a repo - but I don't care that much either
> way.

Since you don't care, we should split them. agents are generally updated
at a much higher ratio than daemons.

Fabio

[Ocfs2-devel] [Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Fabio M. Di Nitto]

On Fri, 2008-11-14 at 15:57 -0600, David Teigland wrote:
> On Fri, Nov 14, 2008 at 10:11:00PM +0100, Andrew Beekhof wrote:
> > I'd have thought fence.git and fence-agents.git in one and cman.git
> > and rgmanager.git in another.
> > But I may be missing some of the interdependencies.
> 
> I wouldn't mind either of those combinations.  Maybe rgmanager's last
> stand will be in cluster.git anyway... if so, then it's not a factor.
> 
> I didn't have much reason for separating fence/fence-agents.  We're
> planning on unifying it all anyway, even if the agents are done sooner.
> And I don't think packaging/releasing agents separately should have much
> bearing on the source tree?  (I've heard interest in putting agents in
> their own package for Fedora.)
> 
> Dave
> 

There is actually an important difference for me to keep them separated.

Each time we do a package update, the whole set of daemons will need to
go through testing again, even if they didn't change a bit.
If we release the 2 components together, users will get both updates at
the same time. Unless you are a super paranoid sysadmin, a yum update or
apt-get update will pull both fenced and fence-agents packages together
(since they come from the same source).
Updating a daemon requires a restart of one bit or another. Updating the
agents no.

I believe that in the long run, and for our users, there is enough time
to save in testing/sysadmin tasks that's worth our initial effort in
bootstrapping them into 2 trees.

Fabio

[Ocfs2-devel] [Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Fabio M. Di Nitto]

On Mon, 2008-11-17 at 09:52 +0100, Andrew Beekhof wrote:
> On Mon, Nov 17, 2008 at 06:52, Fabio M. Di Nitto <fdinitto@redhat.com> wrote:
> > On Fri, 2008-11-14 at 15:57 -0600, David Teigland wrote:
> >> On Fri, Nov 14, 2008 at 10:11:00PM +0100, Andrew Beekhof wrote:
> >> > I'd have thought fence.git and fence-agents.git in one and cman.git
> >> > and rgmanager.git in another.
> >> > But I may be missing some of the interdependencies.
> >>
> >> I wouldn't mind either of those combinations.  Maybe rgmanager's last
> >> stand will be in cluster.git anyway... if so, then it's not a factor.
> >>
> >> I didn't have much reason for separating fence/fence-agents.  We're
> >> planning on unifying it all anyway, even if the agents are done sooner.
> >> And I don't think packaging/releasing agents separately should have much
> >> bearing on the source tree?  (I've heard interest in putting agents in
> >> their own package for Fedora.)
> >>
> >> Dave
> >>
> >
> > There is actually an important difference for me to keep them separated.
> >
> > Each time we do a package update, the whole set of daemons will need to
> > go through testing again, even if they didn't change a bit.
> 
> True.
> 
> Random thought - how about having the resource and fence agents together?
> Similar things with similar update frequencies...

hmmm no.. same reason. they have different tasks.. different subsystems
etc.

Fabio

[Ocfs2-devel] [Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Fabio M. Di Nitto]

On Mon, 2008-11-17 at 11:25 +0100, Andrew Beekhof wrote:
> On Mon, Nov 17, 2008 at 11:02, Fabio M. Di Nitto <fdinitto@redhat.com> wrote:
> > On Mon, 2008-11-17 at 09:52 +0100, Andrew Beekhof wrote:
> >> On Mon, Nov 17, 2008 at 06:52, Fabio M. Di Nitto <fdinitto@redhat.com> wrote:
> 
> >> > There is actually an important difference for me to keep them separated.
> >> >
> >> > Each time we do a package update, the whole set of daemons will need to
> >> > go through testing again, even if they didn't change a bit.
> >>
> >> True.
> >>
> >> Random thought - how about having the resource and fence agents together?
> >> Similar things with similar update frequencies...
> >
> > hmmm no.. same reason. they have different tasks.. different subsystems
> > etc.
> 
> They're still scripts though (and there's not much more difference
> between an IP and IPMI script than there is between an IP and Apache
> script).
> And I'd guess that the chances of each set needing a refresh is about
> the same at any given point in time...

You would still end up with the testing issue we try to avoid by keeping
daemons and agents separated.

Fabio

[Pacemaker] Re: [Cluster-devel] [RFC] Splitting cluster.git into separate projects/trees

[Mark Fasheh]

On Fri, Nov 14, 2008 at 09:33:48AM +0000, Christine Caulfield wrote:
> Fabio M. Di Nitto wrote:
> > Hi everybody,
> > 
> > as discussed and agreed at the Cluster Summit we need to split our tree
> > to make life easier in the long run (etc. etc.).

Thanks for taking this on Fabio.


> > = third approach =
> > 
> > We copy cluster.git N times for each (sub) project, clean the master
> > branch to match only that (sub)project.
> > 
> > Pro:
> >  - very clean tree from checkout
> >  - each (sub) project is really separated and will have its own
> > identity.
> >  - external users don't need to build the whole tree.
> >  - easier to fine tune access to each single component (for example we
> > can allow user foo to access dlm but not gfs... or whatever combination)
> > 
> > Cons:
> >  - more complex process to perform cherry-pick between branches.
> >  - higher risk to commit fixes in one branch and forget in another.
> >  - requires a lot more developer attention.
> 
> 
> I think I would votes for 3, 1, 2 in that order.
> 
> 3 is definitely the best option IMHO. The cons don't make much
> difference really - as I understand it, we're not splitting branches but
> projects so there will be no, or very little, need to copy fixes across
> git trees. Even for the few occasions when it might be necessary, git is
> quite capable of generating usable patches.

I completely agree. Also, yeah the cons don't seem like real cons.

Split out repos for each component is a rather common development model for
free software projects, so I think we're in good company there.

1 and 2 don't really seem like viable long term options to me.
	--Mark

--
Mark Fasheh