On 2013-08-07T19:16:24, Lars Ellenberg <[email protected]> wrote:

Hi all,

sorry for being a bit late to the game. I was on vacation for 2,5 weeks
with no internet-enabled equipment. I can highly recommend the
experience ;-)

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

Of course.

I can see that the reference to "heartbeat" here is confusing for new
people coming to the project. (And I have a subtle feeling that some
old-timers want to complete cutting the cord to the "heartbeat" project
everywhere, too.) That could be solved by using "core" instead as a
provider name.

What I worry about is that this will create confusion with the existing
(and not-yet-reworked) documentation if the reference to "heartbeat"
suddenly no longer works - even if that happened only on a single
distribution. So I'd like to "mandate" the compatibility code.

I'd:
- Rename the provider to "core"
- Rework our own documentation and as we find it
- Transparently support references to "ocf:heartbeat" forever:
  - Re-map s/heartbeat/core/ in the LRM (silently, or it'd get really
    bloody annoying)
  - When a new resource created with that provider, rewrite it to "core"
    with an LOG_INFO message given to the user
  - Hide "ocf:heartbeat" from the normal list (or show it as
    "depreciated, use "core" instead"); but when someone types
    "ocf:heart<TAB>", auto-complete to it and of course auto-complete
    all parameters.
  - Pacemaker's CIB can do this via an XSLT upgrade rule automatically
    too, right? But that might mess with existing customer scripts, so
    maybe we don't want to.

If RHEL dropped the support for the "heartbeat" name completely, I think
this would really suck, because then RHEL would end up with
configuration snippets that suddenly no longer worked on RHEL but
everywhere else. Like, where have we seen that before? ;-) But besides
being bad for RHEL, I think it'd also be bad for the impression of the
community as a whole and the friendliness to users.

So in short: Rename, but remain backwards-compatible (since the price is
low).


Regards,
    Lars

-- 
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 
21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to