[openstack-dev] [TripleO][Tuskar] Icehouse Requirements
tzumainn at redhat.com
Fri Dec 6 21:48:00 UTC 2013
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.
----- Original Message -----
> On Dec 5, 2013, at 9:31 PM, Tzu-Mainn Chen <tzumainn at 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
> Based on the OpenStack Personas, 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.
> > 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev