On Dec 6, 2013, at 8:20 PM, Robert Collins <[email protected]> wrote:
> On 7 December 2013 09:31, Liz Blanchard <[email protected]> wrote: >> This list is great, thanks very much for taking the time to write this up! I >> think a big part of the User Experience design is to take a step back and >> understand the requirements from an end user's point of view…what would they >> want to accomplish by using this UI? This might influence the design in >> certain ways, so I've taken a cut at a set of user stories for the Icehouse >> timeframe based on these requirements that I hope will be useful during >> discussions. >> >> Based on the OpenStack Personas[1], I think that Anna would be the main >> consumer of the TripleO UI, but please let me know if you think otherwise. >> >> - As an infrastructure administrator, Anna needs to deploy or update a set >> of resources that will run OpenStack (This isn't a very specific use case, >> but more of the larger end goal of Anna coming into the UI.) >> - As an infrastructure administrator, Anna expects that the management node >> for the deployment services is already up and running and the status of this >> node is shown in the UI. >> - As an infrastructure administrator, Anna wants to be able to quickly see >> the set of unallocated nodes that she could use for her deployment of >> OpenStack. Ideally, she would not have to manually tell the system about >> these nodes. If she needs to manually register nodes for whatever reason, >> Anna would only want to have to define the essential data needed to register >> these nodes. > > I want to challenge this one. There are two concerns conflated. A) > seeing available resources for scaling up her cloud. B) minimising > effort to enroll additional resources. B) is a no-brainer. For A) > though, as phrased, we're talking about seeing a set of individual > items: but actually, wouldn't aggregated capacity being more useful, > with optional drill down - '400 cores, 2TB RAM, 1PB of disk' Good point. I will update this to read that the user wants to see the available capacity and have the option to drill in further. [1] > >> - As an infrastructure administrator, Anna needs to assign a role to each of >> the necessary nodes in her OpenStack deployment. The nodes could be either >> controller, compute, networking, or storage resources depending on the needs >> of this deployment. > > Definitely not: she needs to deliver a running cloud. Manually saying > 'machine X is a compute node' is confusing an implementation with a > need. She needs to know that her cloud will have enough capacity to > meet her users needs; she needs to know that it will be resilient > against a wide set of failures (and this might be a dial with > different clouds having different uptime guarantees); she may need to > ensure that some specific hardware configuration is used for storage, > as a performance optimisation. None of those needs imply assigning > roles to machines. > >> - As an infrastructure administrator, Anna wants to review the distribution >> of the nodes that she has assigned before kicking off the "Deploy" task. > > If by distribution you mean the top level stats (15 control nodes, 200 > hypervisors, etc) - then I agree. If you mean 'node X will be a > hypervisor' - I thoroughly disagree. What does that do for her? We are in agreement, I'd expect the former. I've updated the use case to be more specific. [1] > >> - As an infrastructure administrator, Anna wants to monitor the deployment >> process of all of the nodes that she has assigned. > > I don't think she wants to do that. I think she wants to be told if > there is a problem that needs her intervention to solve - e.g. bad > IPMI details for a node, or a node not responding when asked to boot > via PXE. > >> - As an infrastructure administrator, Anna needs to be able to troubleshoot >> any errors that may occur during the deployment of nodes process. > > Definitely. > >> - As an infrastructure administrator, Anna wants to monitor the availability >> and status of each node in her deployment. > > Yes, with the caveat that I think instance is the key thing here for > now; there is a lifecycle aspect where being able to say 'machine X is > having persistent network issues' is very important, as a long term > thing we should totally aim at that. > >> - As an infrastructure administrator, Anna wants to be able to unallocate a >> node from a deployment. > > Why? Whats her motivation. One plausible one for me is 'a machine > needs to be serviced so Anna wants to remove it from the deployment to > avoid causing user visible downtime.' So lets say that: Anna needs to > be able to take machines out of service so they can be maintained or > disposed of. > >> - As an infrastructure administrator, Anna wants to be able to view the >> history of nodes that have been in a deployment. > > Why? This is super generic and could mean anything. > >> - As an infrastructure administrator, Anna needs to be notified of any >> important changes to nodes that are in the OpenStack deployment. She does >> not want to be spammed with non-important notifications. > > What sort of changes do you mean here? Good question :) Definitely any failures. I was also thinking there could be certain thresholds on metrics like CPU that a user might want to be notified on. I'll add specific thoughts to the use case. [1] Thoughts? > > ---- > > Thanks for putting this together, I love Personas as a way to make > designs concrete and connected to user needs. Thanks very much for all of the discussion! Liz [1] https://wiki.openstack.org/wiki/TripleO/Tuskar/IcehouseUserStories > > -Rob > > > -- > Robert Collins <[email protected]> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > 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
