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ý <[email protected]> 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 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 [email protected] 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)
pgpAKHTL4tK8m.pgp
Description: PGP signature
_______________________________________________ Developers mailing list [email protected] http://clusterlabs.org/mailman/listinfo/developers
