[openstack-dev] [TripleO][Tuskar] Icehouse Requirements

marios@redhat.com mandreou at redhat.com
Mon Dec 9 15:58:07 UTC 2013


On 07/12/13 04:42, Tzu-Mainn Chen wrote:
>> 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.
> 
> Once nodes are assigned by nova scheduler, would it be accurate to say that they
> have an implicit resource type?  Or am I missing the point entirely?
> 
>>>  * 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.
> 
> Would it be correct to say that Ironic has an inventory of nodes, and that we may
> want to remove a node from Ironic's inventory?

right, in which case (needs to be clarified): Tuskar doesn't store info
about nodes BUT Tuskar (??) the Tuskar UI (??) uses a client to fetch
info directly from Ironic on demand (from the UI).  ??

> 
> Mainn
> 
>> -Rob
>>
>>
>> --
>> Robert Collins <rbtcollins at hp.com>
>> Distinguished Technologist
>> HP Converged Cloud
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list