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

Jaromir Coufal jcoufal at redhat.com
Tue Dec 10 13:51:58 UTC 2013



On 2013/09/12 21:22, Robert Collins wrote:
>> Ironic today will want IPMI address + MAC for each NIC + disk/cpu/memory
>> stats
>>
>> For registration it is just Management MAC address which is needed right? Or
>> does Ironic need also IP? I think that MAC address might be enough, we can
>> display IP in details of node later on.
>
> Ironic needs all the details I listed today. Management MAC is not
> currently used at all, but would be needed in future when we tackle
> IPMI IP managed by Neutron.
OK, I will reflect that in wireframes for UI.

>
>   >       * Auto-discovery during undercloud install process (M)
>>     * Monitoring
>>         * assignment, availability, status
>>         * capacity, historical statistics (M)
>>
>> Why is this under 'nodes'? I challenge the idea that it should be
>> there. We will need to surface some stuff about nodes, but the
>> underlying idea is to take a cloud approach here - so we're monitoring
>> services, that happen to be on nodes. There is room to monitor nodes,
>> as an undercloud feature set, but lets be very very specific about
>> what is sitting at what layer.
>>
>> We need both - we need to track services but also state of nodes (CPU, RAM,
>> Network bandwidth, etc). So in node detail you should be able to track both.
>
> Those are instance characteristics, not node characteristics. An
> instance is software running on a Node, and the amount of CPU/RAM/NIC
> utilisation is specific to that software while it's on that Node, not
> to future or past instances running on that Node.
I think this is minor detail. Node has certain CPU/RAM/NIC capacity and 
instance is consuming it. Either way it is important for us to display 
this utilization in the UI as well as service statistics.

>>      * Resource nodes
>>
>>                          ^ nodes is again confusing layers - nodes are
>> what things are deployed to, but they aren't the entry point
>>
>> Can you, please be a bit more specific here? I don't understand this note.
>
> By the way, can you get your email client to insert > before the text
> you are replying to rather than HTML | marks? Hard to tell what I
> wrote and what you did :).
Oh right, sure, sorry. Should be fixed ;)

> By that note I meant, that Nodes are not resources, Resource instances
> run on Nodes. Nodes are the generic pool of hardware we can deploy
> things onto.
Well right, this is the terminology. From my point of view, resources 
for overcloud are the instances which are running on Nodes. Once we 
deploy the nodes with appropriate software they become Resource Nodes 
(from unallocated pool). If this terminology is confusing already then 
we should fix it. Any suggestions for improvements?

>>      * Unallocated nodes
>>
>> This implies an 'allocation' step, that we don't have - how about
>> 'Idle nodes' or something.
>>
>> It can be auto-allocation. I don't see problem with 'unallocated' term.
>
> Ok, it's not a biggy. I do think it will frame things poorly and lead
> to an expectation about how TripleO works that doesn't match how it
> does, but we can change it later if I'm right, and if I'm wrong, well
> it won't be the first time :).
I think we will figure it out in the other thread (where we talk about 
allocation). Anyway - I am interested in how differently would you 
formulate Unallocated / Resource / Management Nodes? Maybe your is better :)

-- Jarda



More information about the OpenStack-dev mailing list