[
https://issues.apache.org/jira/browse/BIGTOP-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691259#comment-13691259
]
Bruno Mahé commented on BIGTOP-1007:
------------------------------------
{quote}
Yes. However, there is a cost associated with creating every Configuration
object of going to disk and reading those resources added during the directory
scan. The more files there are, the more substantial that cost. Configuration
objects are created all over the place for various reasons. This is why I
wonder if merging to one file is the better option. Could try this suggestion
out though.
{quote}
This is only done on start, isn't it?
And also we are not talking about hundreds of configuration files.
{quote}
Also, instead of having modules.d/ children as collections of files under a
subdirectory, this could simply be a site xml file fragment, e.g.
/etc/hbase/modules.d/phoenix.xml. Forget about the shell scripts, that's just a
ramble.
{quote}
That would work.
{quote}
That's another issue, the coprocessor JAR files must be on the master and
regionserver classpath. Was thinking of modifying the system coprocessor
specifications in hbase site files to allow for optional path to jar instead of
requiring classpath changes.
{quote}
We could have the jars being dumped in a lib directory dedicated to modules and
have that directory referenced in the classpath.
{quote}
I don't think a libexec or jar management is needed, just changes to how
configuration is done.
{quote}
Agreed. /usr/lib/phoenix/phoenix.jar for Phoenix jar is fine.
My main worries with the initial proposal are:
* I am not very fond of auto-generating config files on installation/startup.
There are more rooms for issues. And I don't want to push configuration
management/generation into packaging.
* Even if we generate files, we still need a way for a user to install a module
without activating it
I like a lot the idea of having fragments of configuration because it gives us
the option to activate it or not (through whatever mechanism of our choosing),
and still give to the user the opportunity to customize it.
A coprocessor/module package, should only own the responsibility of itself.
> Introduce a modules system for HBase coprocessor applications
> -------------------------------------------------------------
>
> Key: BIGTOP-1007
> URL: https://issues.apache.org/jira/browse/BIGTOP-1007
> Project: Bigtop
> Issue Type: Improvement
> Affects Versions: 0.7.0
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
>
> Consider a modules system convention ("/etc/hbase/modules.d"), a common
> pattern used for example by Apache httpd, for easily installation and removal
> of HBase coprocessor applications.
> Within the modules.d/ directory, one additional level of subdirectories can
> be created, into which a package can drop site xml fragments and scripts to
> execute after regionserver and master (re)start. Future packages that ship an
> HBase coprocessor application could then add configuration bits without
> concern about collisions and trigger a regionserver reload in postinstall.
> HBase already ships a tool for merging configuration files. Changes required
> for this will be proposed upstream if needed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
