Very nicely done, seeing this stuff laid out is really useful. A few
comments:
= Page 3 =
* Nit: The rocker switch for power is a bit odd to me since it looks
like it can be toggled.
* Can you show an example of a non-healthy node? Is it just an X instead
of a check or are there different degrees/forms of unhealthy that can be
discerned at this level?
* I didn't realize this until the next page and the nodes with bells on
them, but there's no indication in this table of which node may have an
alarm associated with it. Is there no way of viewing the node-alarm
association from this view?
= Page 4 =
* I'm not trying to be a pain in the ass about the counts in the summary
section, but they are kinda confusing me as I try to read this page
without guidance.
** I see 26 nodes but it says 28. That's largely a test data nit that
doesn't affect my understanding.
** It says 0 alarms, but I see three alarm bells. That one is a bit more
than test data anal-retentiveness since it's making me wonder if I'm
interpretting the bells correctly as alarms.
** It looks like this is a grid view, so I might be expecting too much,
but is there any sorting available based on status? I'm guessing the
columns in the previous view can be sorted (which will be very useful)
but without something similar here, I wonder to its effectiveness if I
can't couple the alarmed or non-running machines.
= Page 5 =
* I retract my previous statement about the sorting, the Group By
example is what I was getting at. Can I drill into a particular group
and see just those nodes?
= Page 6 =
* This is a cool idea, showing at the summary level why a node is
unhealthy. What happens if it passes multiple thresholds? Do we just
show one of the problematic values (assuming there's a priority to the
metrics so we show the most important one)?
= Page 10 =
* Nit: The tags seem to take up prime screen real estate for something
I'm not sure is terribly important on this page. Perhaps the intended
use for them is more important than I'm giving credit.
* Is Flavors Consumption always displayed, or is that just the result of
an the alarm? If it was unhealthy due to CPU usage, would that appear
instead/in addition to?
= Page 11 =
* In this view, will we know about configured thresholds? I'm wondering
if we can color or otherwise highlight more at-risk metrics to
immediately grab the user's attention.
On 05/28/2014 05:18 PM, Jaromir Coufal wrote:
Hi All,
There is a lot of tags in the subject of this e-mail but believe me that
all listed projects (and even more) are relevant for the designs which I
am sending out.
Nodes management section in Horizon is being expected for a while and
finally I am sharing the results of designing around it.
http://people.redhat.com/~jcoufal/openstack/horizon/nodes/2014-05-28_nodes-ui.pdf
These views are based on modular approach and combination of multiple
services together; for example:
* Ironic - HW details and management
* Ceilometer - Monitoring graphs
* TripleO/Tuskar - Deployment Roles
etc.
Whenever some service is missing, that particular functionality should
be disabled and not displayed to a user.
I am sharing this without any bigger description so that I can get
feedback whether people can get oriented in the UI without hints. Of
course you cannot get each and every detail without exploring, having
tooltips, etc. But the goal for each view is to manage to express at
least the main purpose without explanation. If it does not, it needs to
be fixed.
Next week I will organize a recorded broadcast where I will walk you
through the designs, explain high-level vision, details and I will try
to answer questions if you have any. So feel free to comment anything or
ask whatever comes to your mind here in this thread, so that I can cover
your concerns. Any feedback is very welcome - positive so that I know
what you think that works, as well as negative so that we can improve
the result before implementation.
Thank you all
-- Jarda
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
