[ClusterLabs Developers] Resurrecting OCF

[Jan Pokorný]

On 19/08/16 13:12 +0200, Jan Pokorný wrote:
> On 19/08/16 11:14 +0200, Jan Pokorný wrote:
>> On 19/08/16 10:59 +0200, Jan Pokorný wrote:
>>> 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"
>> 
>> (apparently missing)
>> 
>>    - $0 "$@"
> 
> (apparently should have been, also in the shortcut path above)
> 
>    - <figured out new path to be called> "$@"
> 
>>> # 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).

...or more complex, but perhaps more systemic solution would be for
__cl_compat__ script to hook into meta-data action, also to set
<resource-agent name="<name>"> correctly.  Hmm, was that parameter
ever useful/meaningful, provided that caller already knows which
name it invoked?  Anyway, that's the place that could carry
use-alias="<alias>" with the same purpose as previously mentioned
new action (that would not normally be announced in metadata,
otherwise we are back at wrapping output of the original...).

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