[ClusterLabs Developers] Resurrecting OCF

Andrew Beekhof andrew at beekhof.net
Wed Sep 21 04:50:20 UTC 2016


I like where this is going.
Although I don’t think we want to get into the business of trying to script config changes from one agent to another, so I’d drop #4


I would make .deprecated a nested directory so that if we want to retire (for example) a ClusterLabs agent in the future we can create .deprecate/clusterlabs/ and put the agent there. Rather than make this heartbeat specific.

I wonder if some of this should live in pacemaker itself though…
If resources_action_create() cannot find ocf:${provider}:${agent} in its usual location, look up ${OCF_ROOT_DIR}/.compat/${provider}/__entries__

Format for __entries__:
   # old, replacement
   # ${agent} , ${new_provider}:${new_agent} , ${description}
   IPaddr , clusterlabs:IP , Replaced with different semantics
   IPaddr2 , clusterlabs:IP , Moved
   drbd , linbit:drbd , Moved
   eDirectory , , Deleted

Assuming an entry is found:
- If  . compat/${old_provider}/${old_agent} exists, notify the user “somehow”, then call it.
- Otherwise, return OCF_ERR_NOT_INSTALLED and use ${description} and ${replacement} as the exit reason (which shows up in pcs status).

Perhaps the “somehow” is creating PCMK_OCF_DEPRECATED (with the same semantics as PCMK_OCF_DEGRADED) and prepending ${description} to the output (assuming its not a metadata op) and/or the exit reason[1].  Maybe only on successful start operations to minimise the noise?

[1] Shouldn’t be too hard with some extra fields for 'struct svc_action_private_s’ or svc_action_t


> On 19 Aug 2016, at 6:59 PM, Jan Pokorný <jpokorny at redhat.com> wrote:
> 
> 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 cluster labs)
> 
> # 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 <mailto: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)
> _______________________________________________
> Developers mailing list
> Developers at clusterlabs.org <mailto:Developers at clusterlabs.org>
> http://clusterlabs.org/mailman/listinfo/developers <http://clusterlabs.org/mailman/listinfo/developers>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20160921/26c232ad/attachment.htm>


More information about the Developers mailing list