On Mar 28, 2008, at 3:07 PM, Dejan Muhamedagic wrote:
On Fri, Mar 28, 2008 at 12:11:11PM +0100, Andrew Beekhof wrote:
On Fri, Mar 28, 2008 at 10:22 AM, Dejan Muhamedagic
<[EMAIL PROTECTED]> wrote:
Hi,
On Fri, Mar 28, 2008 at 11:46:26AM +0900, Simon Horman wrote:
As configure.in currently stands, as of the hg dev tree
54723736ab18,
make dist fails because autogenerated files in snmp_subagent/, in
parcicular snmp_subagent/Makefile.am, are not created.
Andrew Beekhof tells me that this is because snmp_subagent can't
build
without the crm, which is now in the pacemaker tree along with
snmp_subagent.
This fairly minimal patch allows make dist to succeed by not
distributing snmp_subagent/. I have found that building the
resulting
tarball also succeeds.
snmp_subagent also supports heartbeat v1. This puts in the same
category with CTS: some parts are CRM specific and then some are
about heartbeat. I'm not sure how to resolve this.
Basically I think we just need to unapply the patches NTT supplied
for
it (which added v2 support).
Yes, but that would have both packages (heartbeat and pacemaker)
conflict on installation because they would contain same files.
I think we'd just change the name of snmp executable in Pacemaker.
Pacemaker is new, CRM support in SNMP is even newer^... a new name
doesn't seem out of place.
^ mid-December last year, merged by yourself
The question is, is anyone actually using the snmp subagent on a
v1-style cluster?
There is no simple way to find that out.
a) All we'd need is one reply on the mailing list to prove the
statement wrong and veto the removal
b) Resurrecting the code from Hg is trivial (assuming we find out
later someone really was after-all)
c) How much do we want Heartbeat be driven by people that won't even
take part in the community?
I suspect that there is
a good chance that there are people using it.
Then we'll do what we need to do to support those people.
Its not rocket science.
If not, then we should just remove it and maintain it for v2
elsewhere
(currently its in the pacemaker project)
We can't simply just drop a perfectly usable peace of software.
If no-one is using it (which was the condition I very clearly put on
its removal), then whether it is usable or not is completely irrelevant.
Maintaining something with a userbase of zero is pointless, you don't
carry "usable" code around forever "just in case"?.
The only way I can currently think of is to create yet another
package which would contain stuff which depends on both heartbeat
and CRM.
You mean like the GUI?
Which is quite ugly as it serves only to resolve the
build interdependency.
What you call ugly, I call modularization and decoupling - which is
exactly the sort of things we should be thinking about as we look
towards OpenAIS and a common cluster stack
You're really making a much bigger deal out of this than necessary.
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
