Disclaimer: I'm very new to the project, so apologies if some of my
questions have been already answered or flat out don't make sense.
As I proofread, some of my comments may drift a bit past basic
requirements, so feel free to tell me to take certain questions out of
this thread into specific discussion threads if I'm getting too detailed.
--------------------------------
*** 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
It's pretty clear by the current verbiage but I'm going to ask anyway:
"one and only one"?
* 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)
My gut reaction is that we want to bite this off sooner rather than
later. This will have data model and API implications that, even if we
don't commit to it for Icehouse, should still be in our minds during it,
so it might make sense to make it a first class thing to just nail down now.
* optional node profile for a resource class (M)
* acts as filter for nodes that can be allocated to that class
(M)
To my understanding, once this is in Icehouse, we'll have to support
upgrades. If this filtering is pushed off, could we get into a situation
where an allocation created in Icehouse would no longer be valid in
Icehouse+1 once these filters are in place? If so, we might want to make
it more of a priority to get them in place earlier and not eat the
headache of addressing these sorts of integrity issues later.
* 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
Is there more still being flushed out here? Things like:
* Listing unallocated nodes
* Unallocating a previously allocated node (does this make it a
vanilla resource or does it retain the resource type? is this the only
way to change a node's resource type?)
* Unregistering nodes from Tuskar's inventory (I put this under
unallocated under the assumption that the workflow will be an explicit
unallocate before unregister; I'm not sure if this is the same as
"archive" below).
* Archived nodes (F)
Can you elaborate a bit more on what this is?
* 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@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
