Merge lp:~jtv/maas/commissioning-results-ui-tweaks into lp:~maas-committers/maas/trunk
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | no longer in the source branch. |
Merged at revision: | 1963 |
Proposed branch: | lp:~jtv/maas/commissioning-results-ui-tweaks |
Merge into: | lp:~maas-committers/maas/trunk |
Diff against target: |
358 lines (+105/-66) 6 files modified
src/maasserver/templates/metadataserver/nodecommissionresult.html (+8/-6) src/maasserver/templates/metadataserver/nodecommissionresult_list.html (+33/-22) src/maasserver/views/nodecommissionresult.py (+15/-1) src/maasserver/views/nodes.py (+1/-9) src/maasserver/views/tests/test_nodecommissionresults.py (+48/-12) src/maasserver/views/tests/test_nodes.py (+0/-16) |
To merge this branch: | bzr merge lp:~jtv/maas/commissioning-results-ui-tweaks |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Gavin Panella (community) | Approve | ||
Review via email: mp+206732@code.launchpad.net |
Commit message
Tweaks for the commissioning-
Description of the change
These cover the remaining review notes from the original review for this UI: https:/
We have functions similar to normalise_
Jeroen
Looks good. I have lots of comments, but they're mostly around the UI,
and not your changes. Pick out those ones that you want to fix; the rest
is just my commentary on the feature.
[1]
From IRC:
<jtv> allenap: if you want to play with the new feature, edit r/views/ nodes.py and change ENABLE_ NODECOMMISSIONR ESULTS
src/maasserve
to be True.
Why are we using feature flags in trunk?
[2]
+ {% if result_ item.script_ result == 0 %} item.script_ result }}</span>
+ <span>OK: {{ result_
+ {% else %}
I know this probably comes under "systemtic UI review", but I don't
think this needs to include the return code. Just "OK" is enough.
+ <span class="warning"> item.script_ result }}
+ <img src="{{ STATIC_URL }}img/warning.png" title="Failed" />
+ FAILED: {{ result_
+ </span>
+ {% endif %}
Likewise, this doesn't need the return code (it ought to be on the
details page though).
[3]
On the details page, instead of having the 2-column thing at the top,
which takes up a lot of space without telling us much, how about
integrating it into the output:
<breadcrumbs>
Nodes > moon > Commissioning results > 00-maas-01-lshw.out
</breadcrumbs>
<heading>
FAILED
</heading>
<output>
<italics>
Recorded 12:34 on February 17th, 2014.
</italics>
Error while installing lldp: Network unreachable.
<italics>
Exited 1
</italics>
</output>
Maybe that's no good either. I just know that I dislike that 2-column
layout; it's too sparse and light on useful information.
[4]
On http:// localhost: 5240/commission ing-results/ ?node=... I expected to
be able to click on the "/!\ FAILED" bit to see the logs. If I had
wanted to see the logs from an "OK" result I would have wanted to click
in the same column; it is called "Script result" after all.
[4.1]
Same goes for http:// localhost: 5240/nodes/; I want to be able to click
the "Failed tests" status line or the warning triangle to see what's
wrong.
[4.2]
The URL http:// localhost: 5240/commission ing-results/ ?node=... is
slightly disorientating. It would be good to have a view under
/nodes/$id/ to show a page with that node's own results.
[5]
I'm also not sure I care what file it wrote to: 02-virtuality. out means little to me, and I know the
00-maas-
implementation.
[6]
I'm also not sure the Node column is useful on that page. I see that 4671-11e1- 93b8-00225f89f2 11 is
it's a general commissioning results page, narrowed to that particular
node, but I got there by finding "moon" then clicking "3 output files".
To be told that it's for node-29d7ad70-
confusing. Once I understood, it was superfluous.
I guess it needs to be there when showing more than just a single node's
results, but it should then show the node's given name, rather than its
system-generated name.
[7]
On http:// localhost: 5240/nodes/ .../view/ the "Commissioning output" cell
should probably show if commissioning failed too, but perhaps that's
coming later.
[8]
It's not a change you made, but the <pre> block for the output has
excess whitespace within it. <pre> is so anal that it's necessary to
foreg...