Open Stack

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