[ClusterLabs Developers] Resurrecting OCF

[Klaus Wenninger]

On 08/18/2016 05:16 PM, Ken Gaillot wrote:
> 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.

Maybe a way to go for the staging-RAs as well:
Have them in clusterlabs-staging and symlinked (during install
or package-generation) into clusterlabs ... while they are
cleanly separated in the source-tree.

>
> 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).
>
> _______________________________________________
> Developers mailing list
> Developers at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/developers