removing dead files from CVS HEAD

Hi guys,

we have a bunch of files in CVS HEAD that are either unmaintained or not required or have moved to other projects. I would like permission to kill those ones:

clumon/* (moved to conga)
cmirror/Makefile (leftover?)
cs-deploy-tool/* (last changelog update is from 2005. seems abandoned) csnap*/* (seems abandoned)
ddraid/* (seems abandoned)

fence/agents/

according to the Makefile:

SUBDIRS = apc bladecenter brocade bullpap drac egenera ilo ipmilan SUBDIRS += manual mcdata rps10 rsa rsb scsi sanbox2 vixel wti xvm

DISABLEDSUBDIRS = baytech cpint ibmblade primergy rackswitch DISABLEDSUBDIRS += rib vmware xcat xen zvm

there are a bunch of modules that we don't build or install. Does anybody know what is the plan for those?

Thanks
Fabio

PS I didn't mention cmirror-kernel because i think i read on IRC that somebody is working on it again. am I wrong/right?

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

I don't think we want any kernel stuff in cvs HEAD apart from gfs-kernel and gnbd-kernel (and maybe we'll be able to drop gnbd finally). Any kernel bits should use existing processes and trees for moving upstream, e.g. if they are dm targets, then though should live as patches in Alasdair's tree.

ddraid has moved to http://zumastor.googlecode.com/svn/trunk/ so it makes sense to remove all of that.

Userland bits that interact with cman/openais make sense to keep in the cluster tree.

Dave

I think Jon has been using the cmirror-kernel tree to do his development. Would leave that one alone for now. Also, leave csnap for now as Ben has been using that as the basis for some of his work, which hopefully he will be able to get back to at some point.

So, am okay with HEAD containing development/prototype stuff related to clustering and kernel components. They need to live somewhere until accepted into the dm target tree or upstream kernel trees. At that point it would make sense to remove them from HEAD but we need someplace to share content prior to those events occurring.

yes.

Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20070430/c21ceeb0/attachment.htm>

This has somewhat been replaced by Conga, but think it might be still useful to people. Would leave it for now since I don't think it ever made it into a subtree.

kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20070430/1ec47461/attachment.htm>

Stan should be able to answer these..

It basically is. DRBD 0.8 and cmirror + gnbd/iscsi provide similar solutions to the same problem, and are either close to or fully production-ready.

The disabled fence agents are only really disabled probably because historically, we've kept the CVS pool as Red-Hat-centric as possible. That is, we disable things we don't support. From a community perspective, several agents here should still built per-default.

baytech - This is specific to an old Bay Technologies switch IIRC; I do not think this is even made anymore. Probably safe to nuke.

cpint - I don't know what this is.

ibmblade - I don't know what this is.

primergy - I don't know what this is.

rackswitch - I don't know what this is.

rib - Old pre-iLO fencing agent. I don't know if it's safe to remove or not; I assume it's superceded by iLO, so it might be safe to remove.

rps10 - 2-node clusters only - very useful; not network-based power switch. Actually, I don't know why this isn't enabled *now*; it should be.

xcat - I don't know what this is.

xen - kind of superceded by fence_xvm I think - may be safe to remove; Patrick would know.

zvm - Don't nuke this; z/i/p series support will probably require this.

vmware - gsx/esx specific fencing agent. Red Hat doesn't currently ship this agent, but it's community developed, and people use it IIRC.

-- Lon

Lon Hohberger - Software Engineer - Red Hat, Inc.

Ok.

It actually is enabled in SUBDIRS.

This sounds like something we want configurable at build time.

I can make up a patch to the build system that will allow to select individually what fence agents to build. This will allow enough flexibility for each distro to decide what they want to ship.

Fabio

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

Yes, that can go. it was really a stop-gap measure.

Patrick

Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street,
Windsor, Berkshire, SL4 ITE, UK.
Registered in England and Wales under Company Registration No. 3798903

The patch in attachment will allow to specify
--fence_agents="list of fence agents"
at configure time.

default is to build all of them and add a little help section.

The detection of available list is done by checking fence/agents/agent_name/Makefile presence.

It also does another round of Makefile cleanup and fix the Makefiles for previously DISABLEDAGENTS.

Please apply or acknowledge and I will apply.

Thanks
Fabio

I'm going to make him an offer he can't refuse.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 001_make_fence_agents_configurable.dpatch
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20070501/ab284642/attachment.ksh>

We shouldn't be removing agents that we have UI support for, hence xcat needs to stay.

-j

Works for me. I posted a patch later in the thread to do even better :)

Fabio

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

Let's keep in mind that this is cvs HEAD, which is where we're developing stuff for the next generation of products, so we have more latitude in breaking/cleaning/reinventing things.

Dave

ACK

Patrick

Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street,
Windsor, Berkshire, SL4 ITE, UK.
Registered in England and Wales under Company Registration No. 3798903