On Dec 5, 2013, at 9:31 PM, Tzu-Mainn Chen <tzuma...@redhat.com> 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 > 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
