[ClusterLabs Developers] Resurrecting OCF

[Ken Gaillot]

On 08/18/2016 08:31 AM, Kristoffer Grönlund wrote:
> Jan Pokorný <jpokorny at redhat.com> writes:
> 
>> Thinking about that, ClusterLabs may be considered a brand established
>> well enough for "clusterlabs" provider to work better than anything
>> general such as previously proposed "core".  Also, it's not expected
>> there will be more RA-centered projects under this umbrella than
>> resource-agents (pacemaker deserves to be a provider on its own),
>> so it would be pretty unambiguous pointer.
> 
> I like this suggestion as well.

Sounds good to me.

>>
>> And for new, not well-tested agents within resource-agents, there could
>> also be a provider schema akin to "clusterlabs-staging" introduced.
>>
>> 1 CZK
> 
> ...and this too.

I'd rather not see this. If the RA gets promoted to "well-tested",
everyone's configuration has to change. And there's never a clear line
between "not well-tested" and "well-tested", so things wind up staying
in "beta" status long after they're widely used in production, which
unnecessarily makes people question their reliability.

If an RA is considered experimental, say so in the documentation
(including the man page and help text), and give it an "0.x" version number.

> 
> Here is another one: While we are moving agents into a new namespace,
> perhaps it is time to clean up some of the legacy agents that are no
> longer recommended or of questionable quality? Off the top of my head,
> there are
> 
> * heartbeat/Evmsd
> * heartbeat/EvmsSCC
> * heartbeat/LinuxSCSI
> * heartbeat/pingd
> * heartbeat/IPaddr
> * heartbeat/ManageRAID
> * heartbeat/vmware
> 
> A pet peeve of mine would also be to move heartbeat/IPaddr2 to
> clusterlabs/IP, to finally get rid of that weird 2 in the name...

+1!!! (or is it -2?)

> Cheers,
> Kristoffer

Obviously, we need to keep the ocf:heartbeat provider around for
backward compatibility, for the extensive existing uses both in cluster
configurations and in the zillions of how-to's scattered around the web.

Also, despite the recommendation of creating your own provider, many
people drop custom RAs in the heartbeat directory.

The simplest approach would be to just symlink heartbeat to clusterlabs,
but I think that's a bad idea. If a custom RA deployment or some package
other than resource-agents puts an RA there, resource-agents will try to
make it a symlink and the other package will try to make it a directory.
Plus, people may have configuration management systems and/or file
integrity systems that need it to be a directory.

So, I'd recommend we keep the heartbeat directory, and keep the old RAs
you list above in it, move the rest of the RAs to the new clusterlabs
directory, and symlink each one back to the heartbeat directory. At the
same time, we can announce the heartbeat provider as deprecated, and
after a very long time (when it's difficult to find references to it via
google), we can drop it.

I wouldn't even want to update ClusterLabs docs to use the new name
until all major distros have the new resource-agents, which would
probably be at least a couple of years (I'm looking at you, Debian).