[ClusterLabs Developers] Resurrecting OCF

[Jan Pokorný]

On 21/09/16 14:50 +1000, Andrew Beekhof wrote:
> 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

Not agent parameter changes, just its specification -- to reflect
formally what the proposed symlink-based delegation scheme does when
the old one is still in use.  If the old and new are incompatible,
such automatic delegation is not possible anyway (that's one of
the reasons "description" would come handy).

I see there's much bigger potential (parameter renames, ...) but for
that, each agent should be responsible on its own (somehow, subject
of further evolution).

Also, supposing there are more consumers of RA, the suggestion to
run the script should be more generic ("when used from under
pacemaker, ...").

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

Good point; it would also prevent clashes when single directory should
serve all the providers.

> I wonder if some of this should live in pacemaker itself though…

This runs directly to the other side of the RA-pacemaker bias,
pacemaker caring about RA evolutionary internals :-)

In the outlook, that would make any separated OCF standard efforts
worthless and we could just call it pacemaker resource standard
right away and forget about any sort of self-containment
(the proposed procedure aims to align with).

I am not sure that would be the best thing.

> 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

Additional "what happened" field might work well in the update
suggestions.

> 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)
-------------- 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/20160921/b21bd3a2/attachment-0004.sig>