On 08/08/2013, at 3:16 AM, Lars Ellenberg <[email protected]> wrote:
> On Wed, Jul 31, 2013 at 09:47:04AM +1000, Andrew Beekhof wrote: >>>> On 30/07/2013, at 4:21 PM, Ulrich Windl <[email protected]> >>>> wrote: >>>> >>>>>>>> David Vossel <[email protected]> schrieb am 30.07.2013 um 01:20 in >>>>>>>> Nachricht >>>>> <[email protected]>: >>>>> >>>>> [...] >>>>>>> How does this compare to the Red Hat fence/resource-agent packages? I'm >>>>>>> very happy to see "heartbeat" and it's inherent confusion go away, so I >>>>>>> am fundamentally for this. I only question "core" and how it will relate >>>>>>> to those fence and resource agents. >>>>>> >>>>>> "core" would only be related to the ocf standard. I don't think this >>>>>> should >>>>>> have any relation to the fence agents. >>>>> [...] >>>>> >>>>> I wonder: "ocf:base:..." or "ocf:standard:..." instaed of "ocf:core:..." >>>>> >>>>> My personal associations are a bit like this: >>>>> core == essential >>>>> base == basic functions >>>> >>>> many are not basic >>>> >>>>> standard == somewhat standardized >>>> >>>> nor are they a standard (although they do conform to one)... they're just >>>> the >>>> ones that the people upstream ships. >>>> I like this one the least. >>> >>> yeah, standard sounds confusing to me. Splitting agents between >>> core and base is going to be difficult as well. If we did something >>> like that, I'd probably want to do 'core' and 'extended'... where >>> core supported agents are ones the community takes ownership of, and >>> extended agents are agents that exist in the project, but are only >>> maintained by a subset of the community. I don't really want to do >>> something like this though. >>> >>>> >>>> "common" perhaps? >>> >>> perhaps, but I still prefer 'core' over 'common' >>> >>> These are the 'core' resource agents that the ocf community >>> supports. Agents outside of the 'core' provider are supported by >>> different projects and subsets of the community (like linbit and the >>> drbd agent). >> >> I'm convinced. Lars? > > I'm sure LMB has an opinion on this as well. > > But if you are asking for my opinion, > > I don't see the point in renaming those at all. Why? > I also don't see any confusion there. > > If it absolutely has to be done, core or upstream is probably ok. > > And yes, regarding compatibility to existing deployments, > documentation, examples, blogs, and other google foo: > could be solved with a symlink. > > But then: why even bother. > > "heartbeat the communication layer" > is only historically linked to > "heartbeat the ocf resource agent provider", > just because it used to be all in one project, > before it was exploded into all those sub-projets. > > People don't even need to know the former ever existed. > Though I maintain that it is still quite heavily in use... > but that's not the point at all. > > > I simply see no reason to change the name. > It is established, and documented all over the net. > Changing it would be a stupid and unnecessary PR stunt at best, > IMO, and not achieve anything useful. > > > But deep down, I don't really care. > > It's just a name. > > And if you feel offended (or confused) by "heartbeat", > then replace (and symlink) it. > Or, keep it as is, and introduce the other name as alias, > that other name being the symlink. > > I think it's all pointless. Its pointless to people like you and I because we've been around long enough to know that its a meaningless detail. For people just arriving to the project (and there are going to be many of those as the Red Hat folks join in) it appears to be a point of confusion. Google "heartbeat cluster" and the results are rightly about heartbeat the communications layer. Even this week (or last, its a blur sometimes) someone reported a problem with their "heartbeat" cluster only for me so work out that it was really some form of corosync underneath. The docs team here also got confused for a while before I corrected them. QED - Proof by anecdote! > Wait, I said so already ... ;-) > > Cheers, > Lars > > > -- > : Lars Ellenberg > : LINBIT | Your Way to High Availability > : DRBD/HA support and consulting http://www.linbit.com > > DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
