[jira] [Commented] (HBASE-25895) Implement a Cluster Metrics JSON endpoint

["Nick Dimiduk (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-25895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355330#comment-17355330 ] 

Nick Dimiduk commented on HBASE-25895:
--------------------------------------

bq. How does this API definition square with our downstream facing compatibility and versioning promises?

That depends on how we use this. For now, I'd like these endpoints to be considered as internal/private, so that we can experiment and develop with them. Eventually, one day, if this method of UI development catches on, it would be nice to reconcile these APIs with those exposed in the REST Gateway.

bq. If that’s the case we should note it somewhere more prominent because I don’t think downstream users are likely to notice.

Do you have a proposal here? There isn't a way to broadcast intended audience from a webservice... unless we do something terrible. Is a release note on the JIRA good enough?

bq. Pardon, my infoserver knowledge is a bit rusty.

I have no yet performed an audit of what information is exposed through this interface, vs. what is already available on webUIs, vs. what is already available to an authenticated user via the usual client API. What's exposed here is a subset of what's available via client APIs, and I haven't noticed any restrictions on {{Admin}} beyond authentication.

bq. ... but “unprivileged” means that they won’t need to be in any particular access group. Is that correct?

That is consistent with my understanding. TBH, our security filters are pretty clumsy compared to what Jersey offers. For now, I'm implementing within the existing security structures we have in place. If Jersey turns out to work well for us, I'd like to make an effort to overhaul the access filters so that they work more in line with the Jersey model.

From the javadoc strings on these methods,

{noformat}
/**
 * Adds a servlet in the server that any user can access. This method differs from
 * {@link #addPrivilegedServlet(String, ServletHolder)} in that any authenticated user
 * can interact with the servlet added by this method.
 * @param pathSpec The path spec for the servlet
 * @param holder The servlet holder
 */
public void addUnprivilegedServlet(String pathSpec, ServletHolder holder) {
{noformat}

{noformat}
/**
 * Adds a servlet in the server that only administrators can access. This method differs from
 * {@link #addUnprivilegedServlet(String, ServletHolder)} in that only those
 * authenticated user who are identified as administrators can interact with the servlet added by
 * this method.
 */
public void addPrivilegedServlet(String pathSpec, ServletHolder holder) {
{noformat}

bq. We should note this expectation on the package-info for the cluster_metrics package and the class javadocs for the ClusterMetrics api implementation.

Sure, I can add warning notes for developers in more placed in the new code.

bq. If there is some way we can proactively prevent the addition of REST verbs that change state that would also make me feel more at ease with the permissive access.

I'm not aware of anything like this. It might be possible to craft an enforcer rule that fails in the presence of PUT/POST/DELETE annotation verbs. This would be much more strict that anything we have today pertaining to our existing servlets. But still, this wouldn't block changing state per se, only block accepting these types of HTTP requests. Nothing stops a dev from implementing something that changes state via GET query parameters, for example.

> Implement a Cluster Metrics JSON endpoint
> -----------------------------------------
>
>                 Key: HBASE-25895
>                 URL: https://issues.apache.org/jira/browse/HBASE-25895
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Nick Dimiduk
>            Assignee: Nick Dimiduk
>            Priority: Major
>
> In order to build a dynamic visualization functionality, we need access to the underlying dataset. I think we can do a lot by exposing the ClusterMetrics already available via the {{o.a.h.h.client.Admin}} interface.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)