Re: [openstack-dev] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs
Hey Mainn, mostly it is driven by following requirements: https://etherpad.openstack.org/p/ironic-ui plus what you already know from Tuskar point of view - which is simply monitoring, monitoring, monitoring :) Hope it helps -- Jarda On 2014/29/05 05:51, Tzu-Mainn Chen wrote: Hi Jarda, These look pretty good! However, I'm having trouble evaluating from a purely functional point of view, as I'm not entirely sure what the requirements driving these design. Would it be possible to list those out. . . ? Thanks, Tzu-Mainn Chen - Original Message - 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs
On Wed, May 28, 2014 at 10:18 PM, Jaromir Coufal jcou...@redhat.com 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 Just giving a heads up about a work going on in Ironic which affects the way we enroll nodes[1]. tl;dr We want Ironic to support different provisioning methods using the same flavor, e.g the deploy kernel and deploy ramdisk used by the ironic-python-agent[2] is different than the one used by the default PXE driver, so we are moving the deploy KR from the Flavor's extra_specs and adding it to the Node's driver_info attribute (used for storing driver-level information), this will require clients to pass the deploy KR to the node when enrolling it. [1] https://review.openstack.org/#/c/95701/1/specs/juno/add-node-instance-info.rst [2] https://wiki.openstack.org/wiki/Ironic-python-agent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [UX] [Ironic] [Ceilometer] [Horizon] [TripleO] Nodes Management UI - designs
Hi Jarda, These look pretty good! However, I'm having trouble evaluating from a purely functional point of view, as I'm not entirely sure what the requirements driving these design. Would it be possible to list those out. . . ? Thanks, Tzu-Mainn Chen - Original Message - 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
