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