Date

Notification thread

https://lists.apache.org/thread/vomxv36kccwyovbxfpx29snj0rywmocl

http://meet.google.com/sdy-ocrc-fax

Attendees

Discussion Topics

  • Feedback about New Admin UI designs (see Figma)

Post-Meeting Summary

  • "Cluster" is a word not frequently used in Solr, we normally use the word "Cloud"

    • "cloud" could be confused with the Solr mode "SolrCloud", the section however refers to the physical architecture view and therefore "cluster" was chosen initially
    • The sections "Collections" and eventually "ConfigSets" could be considered the logical architecture view
    • Old UI uses "Cloud", so we may simply rename it to "Cloud"
  • Queries & Operations seems not be obvious, requested to be "Queries & Indexing" instead

    • "Index & Query" may be considered instead, for shorter title

  • The curl copy command in Queries was requested and already included, but collapsed and overseen
    • We may reconsider the default collapsed state of specific areas
  • The interaction with the "Queries and Operations" section was a bit confusing
    • In the designs it is not obvious how the forms are updated / behave
      • FYI: By choosing the according request handler, the form in the screen updates accordingly
    • There is potentially the need to use the same mask from one known request handler with other request handlers
      • How could this be realized? Eventually with one more selection field for the form selection?
    • How would custom request handlers be shown / What form would be used there?
  • The word "deamon" seems to be confusing and may be an unwanted "wording"

    • Consider alternative naming or ways for deploying a "deamon", perhaps not provide this feature at all?

    • The deamon stream decorator may be confused with the request field "commitWithin", which are two different things
  • Filter list should be field list (fixed)

  • Playground was a bit hidden and its content (empty atm) not obvious, it can be a top level section called Analysis

    • Analysis tool is a very frequently used tool in the current UI

  • Some clusters may have thousands of collections / cores

    • This could affect the performance of the drop-down collection / core seleciton fields
  • Admin UI is currently focusing only in baisc auth and role based access control
    • Other combinations for AuthX and AuthZ are possible
    • We may limit it to basic auth and role-based access control for now, but it may be subject to change in future
      • Delaying auth implementation might be reasonable
  • Google Sign in and Microsoft sign in options seem questionable

    • The background of these options is the Auth plugin for OAuth / JWT with OIDC
    • Google and Microsoft Identity Providers are often used in companies (via OAuth/OIDC)
      • How does it look in our Solr community?
    • The initial idea of the sign in options (like Google and Microsoft) were simply using the issuer configuration name
    • The Sign In options is subject to change based on our experience and the implementaiton details of the AuthX/AuthZ in the AdminUI
  • There is a concern about having "too much power" in the new Admin UI
    • The Admin UI should reflect the access level in all screens / elements

    • Elements where the user is not authorized to use and blocked by the API will be hidden / disabled

      • Requests should fail anyway

    • The ConfigSets is an example of a "highly privileged" section
    • If the API is not properly blocking unauthorized requests, it is not the Admin UI's problem to limit that, as the frontend can be easily be bypassed

  • In the environment section some values (like JVM STOP.KEY) may be sensitive and should not be displayed
    • Can the API distinguish them?
    • Is there any access control?
    • Should the Admin UI be responsible for hiding specific fields? Who is defining them?
  • The screens in ConfigSets are not optimal and may be further improved
    • It would be great if the schema manipulation is not done by "raw manipulation", using forms for manipulating the schema could be an improvement
  • Individual areas may provide more help / information

    • This could be realized with hint buttons and short descriptions for sections

    • References to the documentation would also be helpful

    • "A good UI should be self-explanatory"

  • Metrics screen made an interesting impression, but is missing important values
    • Y axis has no scale
    • The time of the longest request should be displayed somehow
      • Perhaps in combination with the Y axis max?
      • Network tools from browsers could be used for inspiration
    • Multiple metrics screens are not designed yet
    • Metrics section is postponed for later implementation
  • Slack link in footer was questioned
    • It references to the community-driven Slack group of Solr, not ASF (that is for devs only)
    • Since the current UI already links to the community Slack, this should not be a problem to include in the New UI as well
  • Many places in our API have dynamic fields
    • This could affect predefined filters and tables (for example in "Logging - Logs")
    • We should careful when consuming the API