[
https://issues.apache.org/jira/browse/BIGTOP-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13691014#comment-13691014
]
Andrew Purtell edited comment on BIGTOP-1007 at 6/22/13 1:51 AM:
-----------------------------------------------------------------
bq. Could you please elaborate on what kind of files are you expecting to be
dropped into /etc/hbase/modules.d?
Still have to hack this out. Here's what I'm thinking:
1. An hbase-site.xml file that will be merged with the main file
at/etc/hbase/conf/hbase-site.xml and those of other installed coprocessors. The
union becomes the configuration for HBase, kept in /var/lib/hbase maybe. There
is a tool for merging site files, I want to start with this. May need extension
to control how system coprocessors are ordered in the result. (That would be
done under HBASE-8734.) Think of how Gnome packages regenerate various catalogs
after installation or removal. Since users may edit the files under /etc/hbase,
the init script should check the timestamp of the machine generated file
against the site file(s) under /etc and regenerate as needed.
2. Shell scripts, named something like "master-up", "master-down",
"regionserver-up", and "regionserver-down". To be executed post startup and pre
shutdown accordingly.
So then a coprocessor based HBase "application" can inject just its bits into
the HBase configuration on package install, and easily undo that upon package
removal, without touching the main site file.
So taking Phoenix as an example:
{noformat}
/etc/hbase/modules.d/
phoenix/
hbase-site.xml
master-down
master-up
regionserver-down
regionserver-up
{noformat}
was (Author: apurtell):
bq. Could you please elaborate on what kind of files are you expecting to
be dropped into /etc/hbase/modules.d?
Still have to hack this out. Here's what I'm thinking:
1. An hbase-site.xml file that will be merged with the main file
at/etc/hbase/conf/hbase-site.xml and those of other installed coprocessors. The
union becomes the configuration for HBase, kept in /var/lib/hbase maybe. There
is a tool for merging site files, I want to start with this. May need extension
to control how system coprocessors are ordered in the result. (That would be
done under HBASE-8734.) Think of how Gnome packages regenerate various catalogs
after installation or removal. Since users may edit the files under /etc/hbase,
the init script should check the timestamp of the machine generated file
against the site file(s) under /etc and regenerate as needed.
2. Shell scripts, named something like "master-up", "master-down",
"regionserver-up", and "regionserver-down". To be executed post startup and pre
shutdown accordingly.
So then a coprocessor based HBase "application" can inject just its bits into
the HBase configuration on package install, and easily undo that upon package
removal, without touching the main site file.
> 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
