On 08/18/2016 05:16 PM, Ken Gaillot wrote: > On 08/18/2016 08:31 AM, Kristoffer Grönlund wrote: >> Jan Pokorný <jpoko...@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. > > 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 > Developers@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/developers _______________________________________________ Developers mailing list Developers@clusterlabs.org http://clusterlabs.org/mailman/listinfo/developers