Open Stack

On 7 December 2013 08:15, Jay Dobies <jason.dobies at 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 <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud