That looks really good, thanks for putting that together! I'm going to put together a wiki page that consolidates the various Tuskar planning documents - requirements, user stories, wireframes, etc - so it's easier to see the whole planning picture.
Mainn ----- Original Message ----- > > On Dec 5, 2013, at 9:31 PM, Tzu-Mainn Chen <[email protected]> wrote: > > > Hey all, > > > > I've attempted to spin out the requirements behind Jarda's excellent > > wireframes > > (http://lists.openstack.org/pipermail/openstack-dev/2013-December/020944.html). > > Hopefully this can add some perspective on both the wireframes and the > > needed changes to the tuskar-api. > > 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. > - 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. > - As an infrastructure administrator, Anna wants to review the distribution > of the nodes that she has assigned before kicking off the "Deploy" task. > - As an infrastructure administrator, Anna wants to monitor the deployment > process of all of the nodes that she has assigned. > - As an infrastructure administrator, Anna needs to be able to troubleshoot > any errors that may occur during the deployment of nodes process. > - As an infrastructure administrator, Anna wants to monitor the availability > and status of each node in her deployment. > - As an infrastructure administrator, Anna wants to be able to unallocate a > node from a deployment. > - As an infrastructure administrator, Anna wants to be able to view the > history of nodes that have been in a deployment. > - 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. > > Please feel free to comment, change, or add to this list. > > [1]https://docs.google.com/document/d/16rkiXWxxgzGT47_Wc6hzIPzO2-s2JWAPEKD0gP2mt7E/edit?pli=1# > > Thanks, > Liz > > > > > All comments are welcome! > > > > Thanks, > > Tzu-Mainn Chen > > > > -------------------------------- > > > > *** Requirements are assumed to be targeted for Icehouse, unless marked > > otherwise: > > (M) - Maybe Icehouse, dependency on other in-development features > > (F) - Future requirement, after Icehouse > > > > * NODES > > * Creation > > * Manual registration > > * hardware specs from Ironic based on mac address (M) > > * IP auto populated from Neutron (F) > > * Auto-discovery during undercloud install process (M) > > * Monitoring > > * assignment, availability, status > > * capacity, historical statistics (M) > > * Management node (where triple-o is installed) > > * created as part of undercloud install process > > * can create additional management nodes (F) > > * Resource nodes > > * searchable by status, name, cpu, memory, and all attributes from > > ironic > > * can be allocated as one of four node types > > * compute > > * controller > > * object storage > > * block storage > > * Resource class - allows for further categorization of a node type > > * each node type specifies a single default resource class > > * allow multiple resource classes per node type (M) > > * optional node profile for a resource class (M) > > * acts as filter for nodes that can be allocated to that > > class (M) > > * nodes can be viewed by node types > > * additional group by status, hardware specification > > * controller node type > > * each controller node will run all openstack services > > * allow each node to run specified service (F) > > * breakdown by workload (percentage of cpu used per node) (M) > > * Unallocated nodes > > * Archived nodes (F) > > * Will be separate openstack service (F) > > > > * DEPLOYMENT > > * multiple deployments allowed (F) > > * initially just one > > * deployment specifies a node distribution across node types > > * node distribution can be updated after creation > > * deployment configuration, used for initial creation only > > * defaulted, with no option to change > > * allow modification (F) > > * review distribution map (F) > > * notification when a deployment is ready to go or whenever something > > changes > > > > * DEPLOYMENT ACTION > > * Heat template generated on the fly > > * hardcoded images > > * allow image selection (F) > > * pre-created template fragments for each node type > > * node type distribution affects generated template > > * nova scheduler allocates nodes > > * filters based on resource class and node profile information (M) > > * Deployment action can create or update > > * status indicator to determine overall state of deployment > > * status indicator for nodes as well > > * status includes 'time left' (F) > > > > * NETWORKS (F) > > * IMAGES (F) > > * LOGS (F) > > > > _______________________________________________ > > 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 > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
