On Fri, Mar 28, 2008 at 04:57:13PM +0100, Andrew Beekhof wrote: > > 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
Though a regression, that seems to be a viable option. >>> 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 There are probably more clusters than people reading the list. > 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? This is not about that at all. >> 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. Of course. I wasn't proposing anything else. >>> 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"?. My point was that just taking v1 support out of snmp is not good as there is no easy way to find out if anybody's using it. Whether we like it or not, there are people still running v1. >> 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? Yes. It's just that the GUI is not usable with v1. >> 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 I call it ugly, because the only reason to take it out would be to overcome the heartbeat/CRM separation problem. That's not modularization or decoupling. Looking at it that way, we could create tens of packages. The GUI, for example, is cleanly delineated from the rest not only by its function, but also by usage and deployment. If SNMP support is the only place where there's this kind of conflict, then we could create a separate package and give it a reasonable name (heartbeat-snmp). If there are more, should we then create a separate package for each or put them all together in a single extra packages (called extras?)? > You're really making a much bigger deal out of this than necessary. > Thanks, Dejan _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
