[
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)
