On 7 December 2013 08:15, Jay Dobies <jason.dob...@redhat.com> wrote: > 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.
NP :) >> * 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. We need to be wary of over-implementing now; a lot of the long term picture is moving Tuskar prototype features into proper homes like Heat and Nova; so the more we implement now the more we have to move. >> * 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?) Nodes don't have resource types. Nodes are machines Ironic knows about, and thats all they are. > * 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). Tuskar shouldn't have an inventory of nodes. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
