[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