Open Stack

Thanks for the comments and questions!  I fully expect that this list of requirements
will need to be fleshed out, refined, and heavily modified, so the more the merrier.

Comments inline:

> >
> > *** 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
> 
> Note that everything in this section should be Ironic API calls.
> 
> >    * Creation
> >       * Manual registration
> >          * hardware specs from Ironic based on mac address (M)
> 
> Ironic today will want IPMI address + MAC for each NIC + disk/cpu/memory
> stats
> 
> >          * IP auto populated from Neutron (F)
> 
> Do you mean IPMI IP ? I'd say IPMI address managed by Neutron here.
> 
> >       * Auto-discovery during undercloud install process (M)
> >    * Monitoring
> >        * assignment, availability, status
> >        * capacity, historical statistics (M)
> 
> Why is this under 'nodes'? I challenge the idea that it should be
> there. We will need to surface some stuff about nodes, but the
> underlying idea is to take a cloud approach here - so we're monitoring
> services, that happen to be on nodes. There is room to monitor nodes,
> as an undercloud feature set, but lets be very very specific about
> what is sitting at what layer.

That's a fair point.  At the same time, the UI does want to monitor both
services and the nodes that the services are running on, correct?  I would
think that a user would want this.

Would it be better to explicitly split this up into two separate requirements?

> >    * Management node (where triple-o is installed)
> 
> This should be plural :) - TripleO isn't a single service to be
> installed - We've got Tuskar, Ironic, Nova, Glance, Keystone, Neutron,
> etc.

I misspoke here - this should be "where the undercloud is installed".  My
current understanding is that our initial release will only support the undercloud
being installed onto a single node, but my understanding could very well be flawed.

> >        * created as part of undercloud install process
> >        * can create additional management nodes (F)
> >     * Resource nodes
> 
>                         ^ nodes is again confusing layers - nodes are
> what things are deployed to, but they aren't the entry point
> 
> >         * searchable by status, name, cpu, memory, and all attributes from
> >         ironic
> >         * can be allocated as one of four node types
> 
> Not by users though. We need to stop thinking of this as 'what we do
> to nodes' - Nova/Ironic operate on nodes, we operate on Heat
> templates.

Right, I didn't mean to imply that users would be doing this allocation.  But once Nova
does this allocation, the UI does want to be aware of how the allocation is done, right?
That's what this requirement meant.

> >             * 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)
> 
> Whats a node type?

Compute/controller/object storage/block storage.  Is another term besides "node type"
more accurate?

> 
> >             * optional node profile for a resource class (M)
> >                 * acts as filter for nodes that can be allocated to that
> >                 class (M)
> 
> I'm not clear on this - you can list the nodes that have had a
> particular thing deployed on them; we probably can get a good answer
> to being able to see what nodes a particular flavor can deploy to, but
> we don't want to be second guessing the scheduler..

Correct; the goal here is to provide a way through the UI to send additional filtering
requirements that will eventually be passed into the scheduler, allowing the scheduler
to apply additional filters.

> >         * nodes can be viewed by node types
> >                 * additional group by status, hardware specification
> 
> *Instances* - e.g. hypervisors, storage, block storage etc.
> 
> >         * controller node type
> 
> Again, need to get away from node type here.
> 
> >            * 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
> 
> This implies an 'allocation' step, that we don't have - how about
> 'Idle nodes' or something.

Is it imprecise to say that nodes are allocated by the scheduler?  Would something like
'active/idle' be better?

> >     * 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
> 
> I can't parse this. Deployments specify how many instances to deploy
> in what roles (e.g. 2 control, 2 storage, 4 block storage, 20
> hypervisors), some minor metadata about the instances (such as 'kvm'
> for the hypervisor, and what undercloud flavors to deploy on).

That's what I meant by node distribution (the first word that jumped out
at me when I looked at the wireframes).

> >       * node distribution can be updated after creation
> >    * deployment configuration, used for initial creation only
> 
> Can you enlarge on what you mean here?

This is the equivalent of the options that a user would have before running, say,
packstack.  My understanding is that passing those options in is non-trivial, so
we would just want to expose the default options being used, without allowing
the user to change them.

> >       * 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
> 
> Is this an (M) ?

Ah, you're right to call this out; it needs expansion.  I'm guessing that having
a notification when a deployment deploys successfully should be possible during
the Icehouse timeframe; having a notification when there's an error or something
is more of an (M).

> > * DEPLOYMENT ACTION
> >    * Heat template generated on the fly
> >       * hardcoded images
> >          * allow image selection (F)
> 
> We'll be spinning images up as part of the deployment, I presume - so
> this is really M, isn't it? or do you mean 'allow supplying images
> rather than building just in time' ? Or --- I dunno, but lets get some
> clarity here.

Tuskar currently doesn't allow you to actually specify what image is spun up
as part of the deployment.  This requirement is about allowing users to upload
their own images and have them be used in the deployment.

> >       * 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)
> 
> What does this mean?

The proposed requirement is that within a deployment, a user can specify a resource class, and then
specify a 'node profile' that lists the requirements necessary for a node to be placed in that class.
Upon deployment, that information is passed through to the scheduler, which uses them in its filters
when picking nodes.

> 
> Sorry for having so many questions :)

Not at all!  Again, thank you for asking them, and sorry for adding some of my own :)

Mainn
 
> -Rob
> 
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>