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.
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
