Open Stack

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 <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
> 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>