On Dec 9, 2013, at 4:29 AM, Jaromir Coufal <jcou...@redhat.com> wrote:
> > On 2013/06/12 22:55, Matt Wagner wrote: >>> - As an infrastructure administrator, Anna wants to review the >>> distribution of the nodes that she has assigned before kicking off >>> the "Deploy" task. >> What does she expect to see here on the review screen that she didn't >> see on the previous screens, if anything? Is this just a summation, or >> is she expecting to see things like which node will get which role? (I'd >> argue for the former; I don't know that we can predict the latter.) > At the beginning, just summation. Later (when we have nova-scheduler > reservation) we can get the real distribution of which node is taking which > role. Yes, the idea is that Anna wants to see some representation of what the distribution of nodes would be (how many would be assigned to each profile) before kicking off the "deploy" action. > >>> - As an infrastructure administrator, Anna wants to monitor the >>> deployment process of all of the nodes that she has assigned. >> I think there's an implied "...through the UI" here, versus tailing log >> files to watch state. Does she just expect to see states like "Pending", >> "Deploying", or "Finished", versus, say, having the full logs shown in >> the UI? (I'd vote 'yes'.) > For simplified view - yes, only change of states and progress bar. However > log should be available. I'd vote 'yes' as well. These are definitely design decisions we should be making based on what we know of our end user. Although some use cases like troubleshooting might point towards using logs, this one definitely seems like a UI addition. I'll update the use case to be more specific. [1] > >>> - As an infrastructure administrator, Anna needs to be able to >>> troubleshoot any errors that may occur during the deployment of nodes >>> process. >> I'm not sure that the "...through the UI" implication I mentioned above >> extends here. (IMHO) I assume that if things fail, Anna might be okay >> with us showing a message that $foo failed on $bar, and she should try >> looking in /var/log/$baz for full details. Does that seem fair? (At >> least early on.) > As said above, for simplified views, it is ok to say $foo failed on $bar, but > she should be able to track the problem - logs section in the UI. Yes, this is meant to be through the UI. I've updated the use case. [1] > >>> - As an infrastructure administrator, Anna wants to be able to view >>> the history of nodes that have been in a deployment. >> Why does she want to view history of past nodes? >> >> Note that I'm not arguing against this; it's just not abundantly clear >> to me what she'll be using this information for. Does she want a history >> to check off an "Audit log" checkbox, or will she be looking to extract >> certain data from this history? > Short answer is Graphs - history of utilization of the class etc. I've updated this one to be more specific about the reasons why historic nodes is important to Anna. [1] Thanks for all of the feedback, Liz [1] https://wiki.openstack.org/wiki/TripleO/Tuskar/IcehouseUserStories > > -- 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
