accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From joshelser <>
Subject [GitHub] accumulo issue #242: ACCUMULO-2181/3005 REST API and new Monitor UI
Date Thu, 13 Apr 2017 23:56:17 GMT
Github user joshelser commented on the issue:
    > One of the design changes I made was to remove the footer (makes it for a cleaner
look on large tables) and move it to the "About" section. However, we could add the Accumulo
logo later on to the header (maybe even set a link to the Accumulo website?).
    I don't have a good suggestion here, just that my gut-reaction was that it was very light
on "apache accumulo". I think we should do more here, but I don't have concrete suggestions
at the moment. We should definitely make sure it's clearly branded and something we're proud
    > I believe the 13 calls happen only on the overview (since we are getting all the
information for the plots), but in other pages we also do multiple calls (like in the master
    Yes, I was talking about index (with the graphs).
    > "default" != "accumulo". The "default" namespace is the one where created tables
get "assigned" to if the user didn't specify a namespace, the "accumulo" namespace I believe
is just for the Replication, Root, and Metadata tables (could be mistaken?).
    My point was that I selected "All", and I got an extra two filters (default and accumulo).
All should encompass everything -- it was confusing that I had those extra filters which were
meaningless (because I already said "give me all the tables").
    > I tried to write some Java documentation that would be useful for generating the
JavaDocs, but it might be good for someone with more knowledge of Accumulo (and Java) to check
that the wording is good for it.
    Docs for the java objects is fine, but I meant REST API docs. As I understand it, Swagger
is pretty common ( Describes
what REST endpoints exist, what options they accept and the responses they return.
    For context: a big knock against the "old" monitor is that the XML/json endpoints did
not return all of the information that the Monitor had available/used. Ensuring that endpoints
for all of the data we're using to render HTML was also available to administrators was a
big design goal of this approach. Thus, organizations how have custom monitoring/dashboards
can scrape these endpoints and integrate the data with whatever solution(s) they use.
    > we should revisit the summaries in the future to clean them up (I didn't change the
wording from the original Monitor).
    Agreed. This is a pretty clear-cut one that needs revisiting before release.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message