[openstack-dev] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs

Jay Dobies jason.dobies at redhat.com
Mon Jun 2 14:12:53 UTC 2014


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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list