Date
Notification thread
https://lists.apache.org/thread/vomxv36kccwyovbxfpx29snj0rywmocl
Meeting Link
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?
- In the designs it is not obvious how the forms are updated / behave
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