[Linux-ha-dev] Re: [patch 01/12] build: Dont distribute snmp_subagent

[Andrew Beekhof]

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
>> <dejan at hello-penguin.com> 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.