Difference between revisions of "TripleO/TuskarIcehouseRequirements"
< TripleO
(→Registration) |
|||
| Line 48: | Line 48: | ||
* unregister | * unregister | ||
| − | + | ||
| − | |||
== Deployments == | == Deployments == | ||
| Line 83: | Line 82: | ||
* ''review distribution map (**)'' | * ''review distribution map (**)'' | ||
* notification when a deployment is ready to go or whenever something changes | * notification when a deployment is ready to go or whenever something changes | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Tests == | == Tests == | ||
* comprehensive unit test coverage | * comprehensive unit test coverage | ||
* integration tests (through Tempest) | * integration tests (through Tempest) | ||
| + | |||
| + | == "Future (**)" == | ||
| + | * ''Networks (**)'' | ||
| + | * ''Images (**)'' | ||
| + | * ''Logs (**)'' | ||
| + | * ''Archived nodes (**)'' | ||
Revision as of 20:58, 9 December 2013
Contents
Overview
This document lists known requirements for the Icehouse release, as well as requirements that may not make it into Icehouse, but which will affect our design. The relevant mailing list discussion can be found here.
All requirements here are assumed to be targeted for Icehouse, except where otherwise marked:
- * Maybe Icehouse, dependency on other features being developed in the Icehouse timeframe
- ** After Icehouse
Nodes
Registration
- Manual registration
- hardware specs from Ironic based on IPMI address and MAC address (*)
- IPMI address auto populated from Neutron (**)
- Node auto-discovery(*)
Monitoring
- assignment, availability, status
- capacity, historical statistics (*)
Management node
- where undercloud is installed
- created as part of undercloud install process
- allow creation of additional management nodes through UI (**)
Resource nodes
- can be allocated by nova-scheduler as one (and only one) of four node types
- compute
- controller
- each controller node will run all openstack services
- allow each node to run a specified service (**)
- breakdown by workload (percentage of cpu used per node) (*)
- each controller node will run all openstack services
- 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 (*)
- Node profile for a resource class (*)
- acts as an optional filter for nodes that can be allocated to that class (*)
- each node type specifies a single default resource class
- once allocated, can be unallocated
- searchable by status, name, cpu, memory, and all attributes from ironic
- nodes can be viewed by node types
- additional 'group by' with status, hardware specification
Unallocated nodes
- list
- unregister
Deployments
General
- only a single deployment allowed
- allow multiple deployments (**)
Node distribution
- deployment can specifiy a node distribution across node types
- node distribution can be updated after creation
Deployment configuration
- deployment configuration, used for initial creation only
- defaulted, with no option to change
- allow modification (**)
Deployment Action
- Heat template generated on the fly
- hardcoded images
- allow image selection (**)
- pre-created template fragments for each node type
- node type distribution affects generated template
- hardcoded images
- nova scheduler allocates nodes
- nova scheduler filters based on resource class and node profile information (*)
- Deployment action can create or update
- status indicator to determine overall state of deployment
- status indicator for nodes as well
- status includes 'time left' (**)
Other
- review distribution map (**)
- notification when a deployment is ready to go or whenever something changes
Tests
- comprehensive unit test coverage
- integration tests (through Tempest)
"Future (**)"
- Networks (**)
- Images (**)
- Logs (**)
- Archived nodes (**)
