The relevant wiki page is here: https://wiki.openstack.org/wiki/TripleO/Tuskar#Icehouse_Planning
----- Original Message ----- > 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 > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
