[
https://issues.apache.org/jira/browse/HBASE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292384#comment-13292384
]
Andrew Purtell edited comment on HBASE-6193 at 6/9/12 5:01 PM:
---------------------------------------------------------------
bq. Otherwise each new feature implemented in the region server, the rest
gateway should be updated with corresponding new feature.
I'm not sure this holds.
There is client activity, and then there is administrative activity.
Certainly for each new feature implemented in the client, the REST interface
should be updated, whatever its form. See the RemoteHTable class in
o.a.h.hbase.rest.client. I suppose also RemoteHAdmin to provide full API
coverage available to Java clients.
Our existing design does the above and adds small InfoServer based servers for
other types of administrative activity, like querying JMX exported information
in JSON encoding. You may not want to allow users to do that. The current
design segregates client and that second class of administrative access well.
I really think you need to produce a design document that covers all of these
issues and makes a convincing argument before we can proceed further.
Edit: It bears repeating, but I am not opposed to your approach in principal.
However a big design change like this requires justification that I'm just not
seeing yet.
was (Author: apurtell):
bq. Otherwise each new feature implemented in the region server, the rest
gateway should be updated with corresponding new feature.
I'm not sure this holds.
There is client activity, and then there is administrative activity.
Certainly for each new feature implemented in the client, the REST interface
should be updated, whatever its form. See the RemoteHTable class in
o.a.h.hbase.rest.client. I suppose also RemoteHAdmin to provide full API
coverage available to Java clients.
Our existing design does the above and adds small InfoServer based servers for
other types of administrative activity, like querying JMX exported information
in JSON encoding. You may not want to allow users to do that. The current
design segregates client and that second class of administrative access well.
I really think you need to produce a design document that covers all of these
issues and makes a convincing argument before we can proceed further.
> REST Api for HBase administrative tasks
> ---------------------------------------
>
> Key: HBASE-6193
> URL: https://issues.apache.org/jira/browse/HBASE-6193
> Project: HBase
> Issue Type: New Feature
> Reporter: Eric Yang
>
> For enabling HBASE-4368, it may be useful to have embedded REST API server
> for each region server, and HBase Master can either aggregate or
> proxy/redirect REST API base on administrative task functions.
> The popular admin task that can take advantage of this setup are:
> - Trigger table compaction
> - Show process list
> - Health check
> - Show black listed servers
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
