[ClusterLabs Developers] Resurrecting OCF

[Jan Pokorný]

On 18/08/16 17:27 +0200, Klaus Wenninger wrote:
> 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.

So, having some more thoughts on this, here's the possible action
plan (just for heartbeat -> clusterlabs transition + deprecating
some agents, but clusterlabs-staging -> clusterlabs would be similar):

# (adapt and) move original heartbeat agents

1. have a resource.d subdirectory "clusterlabs" and move (possibly under
   new names) agents that were a priori updated to reflect new revision
   of OCF there

2. have a resource.d subdirectory ".deprecated" (for instance) and
   move the RAs that are going to be sunset over there (i.e.,
   original heartbeat agents = agents moved to clusterlabs + agents
   moved to .deprecated + agents that remained under heartbeat, pending
   to be moved under clusterlabs)

# preparation for backward compatibility

3. have a file with old heartbeat name -> new clusterlabs name mapping
   for the agents from 0., i.e., hence physically changed the directory;
   the format can be as simple as CVS with "old name; [new name]" lines
   where omitted new name means that actual name hasn't changed
   (unlike proposed IPaddress2 -> IP)

4. have an XSL template that will convert resource references per the
   translation file from 3. (this XSLT should be automatically
   generated based on that file) and a script that will call
   something like:
   cibadmin -Q | xsltproc <XSLT> - | cibadmin --replace --xml-pipe

5. have a shell script "__cl_compat__" (for instance, name clearly
   distinguishable will become handy later on), that will:
   - figure which symlink it was called under ("$0") and figure out
     how it should behave based on file from 3.:
     . $0 found as old name with new name -> clusterlabs/<new name>
       will be called
     . $0 found as old name without new name -> clusterlabs/<old name>
       will be called
     . $0 not found as old name -> .deprecated/<old name> will be
       called if exists (otherwise fail early)
   - if "$HA_RSCTMP/$(basename $0)_compat" exists, just run:
     $0 "$@"; exit $?
     the purpose here is to avoid excessive spamming in the logs
   - touch "$HA_RSCTMP/$(basename $0)_compat"
   - emit a warning "Your configuration referes to the agent with
     an obsolete specification", followed with corresponding:
      . "please consider changing ocf:heartbeat:<old name> to
         ocf:clusterlabs:<new name>, you may use <script from 4.>
	 to ease such transition"
      . "please consider changing ocf:heartbeat:<old name> to
         ocf:clusterlabs:<old name>, you may use <script from 4.>
	 to ease such transition"
      . "please consider finding another alternative for
         ocf:heartbeat:<old name> as this agent is not actively
	 maintained and will be dropped in the next major release;
	 alternatively, if you volunteer to maintain it,
	 please reach developers at clusterlabs.org mailing list"

# plugging it all together

6. for agents moved from heartbeat in any of clusterlabs/.deprecated,
   (items 1. and 2.), provide respective symlinks from heartbeat
   pointing to __cl_compat__ script from 5.

Possibly recycle for clusterlabs-staging idea.


Now, for the higher level tools (crm, pcs), they should avoid listing
or suggesting agents that are symlinks to files matching wildcard
"__*__", and perhaps even actively suggest the alternative if this
such one is to be used -- this could be reached by making __compat__
script from 5. handle one new action (to be reflected in the OCF
revision as optional), say "new-alias" that would output what
to use instead (based on file from 3. it works with anyway).

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

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20160819/b688e5a8/attachment-0004.sig>