On 06/12/13 04:31, Tzu-Mainn Chen 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. > > 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
sorry am a bit late to the discussion - fyi: ^^^^ there are two sides to these previous points 1) temp solution using merge.py from tuskar and the tripleo-heat-templates repo. (Icehouse, imo) and 2) doing it 'properly' with the merge functionality pushed into heat. (F, imo). For 1) various bits are in play: fyi/if interested: /#/c/56947/ (Make merge.py invokable), /#/c/58823/ (Make merge.py installable) and /#/c/52045/ (WIP : sketch of what using merge.py looks like for tuskar) this last one needs updating and thought. Also /#/c/58229/ and /#/c/57210/ which need some more thought, > * 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev