[
https://issues.apache.org/jira/browse/BIGTOP-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691239#comment-13691239
]
Andrew Purtell commented on BIGTOP-1007:
----------------------------------------
bq. Instead of merging/generating files, can we enhance Apache HBase so it
picks up all files from a given directory
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.
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.
bq. Or maybe making the files available to Apache HBase (ie. jars) but having
hbase-site specifying which module to activate?
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.
Instead of a modules.d/ directory under /etc there could be a libexec where
jars are dropped. Site configuration files could be packaged in the jar, like
WARs. However, then admins or Puppet cannot go customize that configuration. I
think we need a tree of easily modifiable config files.
If there is only one hbase site file, then the package installer must modify
that global hbase site file in pre and post install scripts. This is what I
would like to avoid because who knows what other configuration variables the
"application" will want to set. sed won't reliably work in the presence of hand
edits but rm is easy.
> 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
