[ClusterLabs Developers] Resurrecting OCF

[Klaus Wenninger]

On 08/20/2016 12:08 AM, Jan Pokorný wrote:
> 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...).

Remember to have used a link to an OCF-Agent - which had
a slightly different behavior when called via the link - before.
As far as I remember the meta-data was static though and
it was working as supposed.
But that was some time ago and I was using crmsh.
I guess the place to check if a divergence between
meta-data and filename creates troubles would be the
high-level tooling.
Anyway an alternative way to go here might be to allow
an asterisk (or more complex the introduction of a
variable holding the file(link)-name or maybe even
just using `basename $0`) here for the meta-data that
is filled automatically according to file/link-name.
>
>
>
> _______________________________________________
> Developers mailing list
> Developers at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/developers